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CHAPTER  13 


MOVEMENT  MODEL 


j  1.  MILITARY  L'NIT  MOVEMENT.  The  DIVWAG  Movement  Model  is  designed  to  represent 
the  movement  of  military  units  about  the  battlefield.  The  model  accomplishes 
the  repositioning  of  units  by  considering  characteristic  administrative  or 
tactical  movement  rates  for  the  type  unit  to  be  moved;  the  effects  of  barriers 
and  facilities  that  may  tend  to  impede  or  improve  the  unit's  movement  capabil¬ 
ity;  the  effects  of  variations  in  terrain,  weather,  and  light  conditions  on 
the  unit's  movement  capability;  and  the  availability  of  fuel. 

a.  DSL-Ordered  Movement.  Tactical  and  administrative  movement  of  units 
by  ground  or  air  in  the  Movement  Model  is  usually  in  response  to  gamer-planned 
DSL  orders.  The  gamer  must  plan,  coordinate,  and  schedule  all  movement  per¬ 
formed  by  this  model,  except  that  controlled  by  the  Engineer  Model. 

b.  Model-Ordered  Movement.  The  Engineer  Model  sets  up  the  necessary 
parameters  and  calls  the  Movement  Model,  allowing  it  to  perform  the  actual 
relocation  of  an  engineer  unit.  The  Engineer  Model  is  described  in  Chapter  14 
to  this  section. 

c.  Automatic  Movement.  For  the  most  part,  movements  of  units  not  in 
direct  response  to  gamer  input  orders  are  accomplised  within  other  models  of 
the  DIVWAG  System.  The  Ground  Combat  Model  (Chapter  7)  moves  maneuver  units 
while  they  are  actually  engaged  in  combat,  the  Combat  Service  Support  Model 
(Chapter  16)  controls  logistic  movements,  and  the  Air  Ground  Engagement  Model 
(Chapter  10)  accomplishes  the  movement  of  air  units  when  this  movement  is  in 
response  to  automatically  generated  missions.  The  reconnaissance  portion  of 
the  Intelligence  and  Control  Model  regulates  movement  of  reconnaissance  units 
and  subunits.  Treatment  of  these  movement  categories  is  documented  with  the 
appropriate  models. 

*  2.  MODEL  DESIGN: 

a.  General.  The  Movement  Model  is  designed  to  represent  aerial  and 
ground  movement  capabilities  using  a  four-phase  process  to  integrate  gamer- 
planned  and  scheduled  unit  movement  into  dynamic  unit  locations  within  the 
DIVWAG  System  during  the  game  period.  This  process  is  illustrated  in  Figure 
,  IV-13-1,  Movement  Model  Macroflow,  with  the  phases  identified  as  I,  II,  III, 

and  IV.  Briefl-,  these  four  phases  consist  of  the  development  of  DSL  movement 
orders:  phase  I;  the  integration  of  these  orders  into  model  path  segments, 
phase  II;  the  determination  of  the  appropriate  unit  rate  along  these  model 
paths,  phase  III;  and,  finally,  the  performance  of  the  unit's  movement  along 

*  the  model  segment  and  the  update  of  unit  location  and  consumption  data, 
phase  IV.  The  last  three  phases  are  internally  performed  during  the  dynamic 
game  period  by  the  movement  submodels,  tJhile  the  initial  phase  is  performed 
external  to  the  Movement  Model  as  a  gamer  function  or  internal  function  of 
another  model. 


( 
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(1)  Unit  Movement  Planning,  Phase  I.  Briefly,  the  first  phase 
consists  of  the  planning,  coordination,  and  scheduling  of  unit  movement  and, 
in  the  case  of  gamer-ordered  movements,  is  accomplished  prior  to  each  game 
period.  (planning  accomplished  internal  to  other  models  is  documented  with 
tnose  models).  Phase  I  provides  the  Movement  Model  with  movement  parameters 
from  which  to  generate  the  required  unit  movement.  Although  this  first  phase 
is  external  to  the  movement  submodels  representing  the  other  three  phases  in 
the  figure,  it  nonetheless  provides  the  vital  information  necessary  to  generate 
unit  movement  within  the  model.  The  DSL  orders  pertinent  to  phase  I  are 
discussed  in  subparagraph  b(l)  below. 

(2)  Model  Move  Segments  and  Coordination.  Phase  II  is  the  move 
segment  determination  and  coordination  (routine  MOVESR)  and  functions  to  inte¬ 
grate  the  movement  orders  into  scheduled  model  move  segments  within  the  DIVWAG 
system.  This  routine  divides  the  total  move  path  (order  segment)  into  model 
move  segments,  the  endpoints  of  which  specify  the  positions  where  the  units 
are  actually  located  within  the  model.  This  submodel  also  integrates  effects 
of  barriers  and  facilities  on  movement  into  the  unit's  movement  schedule  when 
required  to  do  so. 

(3)  Unit  Movement  Timing.  The  movement  rate  determination  routine 
(MOVEDT)  establishes  the  appropriate  unit  movement  rates  along  the  model's 
move  segments.  This  rate,  when  combined  with  the  length  of  the  move  segment, 
provides  the  time  sequencing  information  needed  to  schedule  the  completion 
time  of  the  model's  movement  event  activity. 

(4)  Move  Segment  Completion.  The  performance  of  the  move  along  the 
model  segment  is  accomplished  in  the  fourth  phase  by  the  move  performance 
routine  (MOVE).  In  this  routine  the  unit's  location  in  the  model  is  updated, 
and  the  unit's  consumption  of  food  and  fuel  along  the  move  segment  is  recorded. 

b.  Specific  Model  Design.  This  paragraph  discusses  the  specific  desgin 
aspects  of  the  Movement  Model  applying  to  the  overall  model.  It  provides  a 
summary  overview  of  the  various  submodel  functions.  The  model  design  is  dis¬ 
cussed  with  respect  to  four  topics:  DSL  movement  orders,  model  move  segments, 
unit  movement  rates,  and  the  Movement  Model  interfaces  with  other  DIWAG 
models. 


(1)  DSL  Movement  Orders.  The  gamer  DSL  orders  that  schedule  the 
simulated  ground  movement  in  the  model  are  move,  advance,  and  withdraw.  The 
corresponding  order  for  air  movement  is  the  fly  order.  A  typical  ground  move¬ 
ment  order  given  to  a  unit  might  be  of  the  following  form: 

STAY  UNTIL  0800. 

MOVE  TO  Xi-Yi,  X2-Y2,  Xp-YD  BY  TRGM. 

The  movement  path  schematic  for  the  unit  given  such  an  order  is  illustrated 
in  Figure  IV-13-2.  The  DSL  ground  movement  order  contains  the  Movement  Model 
parameters  in  the  form  of  the  travel  mode  mnemonic,  TRGM;  the  specific  type 
of  move  order,  MOVE;  the  series  of  DSL  path  segment  endpoints  specifying  the 
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Figure  IV-13-2.  DSL  Move  Path  Schematic 
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travel  route  to  be  followed,  Ii,  12 ,  and  0;  and  the  scheduled  tine  of  depar¬ 
ture,  0800,  as  determined  by  the  stay  order  immediately  preceding  the  move 
order.  (Nonmovement,  or  remaining  in  position,  is  accomplished  by  the  stay 
and  prepare  orders  for  ground  units  and  by  the  loiter  order  for  air  units). 

(a)  Travel  Mode  Mnemonic.  The  travel  mode  mnemonic  contains  the 
gamer  specification  of  the  type  of  unit  movement  desired,  the  route  type, 
and  the  unit's  formation  type.  The  type  -T  unit  movement  requested  may  be 
administrative  or  tactical: 

A  -  Administrative.  This  category  implies  movement 
of  units  by  road  nets  and  uses  the  most  effi¬ 
cient  transportation  systems  available  with 
tactical  considerations  of  secondary  importance. 

T  -  Tactical.  Movement  of  this  type  includes  cross 
country;  movement  in  partially  deployed,  re¬ 
connaissance,  or  column  march  formations;  and 
tactical  road  marches  as  part  of  an  attack, 
withdrawal,  or  other  tactical  plan  external 
to  maneuver  movement  within  ground  combat 
engagements . 

The  route  type  defined  in  the  DSL  travel  mode  mnemonic  is  one  of  the  following 
types: 

CC  -  Cross  Country.  Route  of  the  unit  is  subject 
to  natural  terrain  conditions  existing  in 
its  path. 

RA  -  Paved  Roads.  This  route  type  is  such  that 
road  beds  are  asphalt  or  concrete  with  at 
least  two  lanes  with  good  shoulders,  and 
the  route  is  not  significantly  dependent 
upon  short  range  or  local  terrain  features. 

RG  -  Gravel  Roads.  Route  is  gravel  or  similar 
surfaced  road  with  periodic  maintenance. 

RD  -  Dirt  Roads.  Route  is  dirt,  road  is  narrow 
and/or  marginally  maintained  and  is  sub¬ 
ject  to  terrain  undulations  and  other 
local  terrain  features. 

The  unit  formation  is  specified  as  column  march  formation,  reconnaissance,  or 
deployed,  and  is  identified  as: 
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M  -  Column  March.  The  unit  is  in  a  column 
formation  on  a  road  or  cross  country 
route. 

R  -  Reconnaissance.  Deployment  pattern  on 
cross  country  by  a  unit  on  a  ground 
reconnaissance  type  mission. 

D  -  Deployed.  Unit  is  partially  deployed  in 
a  formation  in  anticipation  of  imminent 
contact  with  the  enemy. 

The  letters  composing  the  travel  mode  mnemonic  are  used  in  the  model  to 
identify  the  movement  parameters  applicable  to  the  current  unit  movement. 

The  first  character  specifies  the  move  type,  the  second  and  third  are  used  to 
indicate  the  route  type,  and  the  fourth  is  used  to  designate  the  formation 
type.  The  various  combinations  allowed  in  any  particular  game  are  defined 
in  the  pregame  data  preparation  process.  A  typical  group  used  for  a  game 
might  be  as  follows: 

ARAM  -  Administrative  move  on  all-weather  roads 
in  march  column  formation. 

ARGM  -  Administrative  move  on  gravel  roads  in 
march  column  formation. 

TRAM  -  Tactical  move  on  asphalt,  concrete,  or 

similar  paved  road  in  a  march  column  formation. 

TRGM  -  Tactical  move  on  improved,  gravel,  or 
similar  surfaced  roads  in  a  march 
column  formation. 

TRDM  -  Tactical  move  on  unpaved  or  dirt  roads 
in  a  march  column  formation. 

TRGR  -  Tactical  move  on  improved,  gravel  roads 
in  a  reconnaissance  type  formation. 

TCCM  -  Tactical  cross  country  move  in  a  march 
column  formation. 

TCCR  -  Tactical  cross  country  move  in  a  reconnaissance 
formation. 

TCCD  -  Tactical  cross  country  move  in  a  deployed 
formation. 

The  travel  mode  mnemonic  is  discussed  extensively  in  Appendix  A  to  this  chapter. 
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(b)  Travel  Route.  In  addition  to  the  type  of  route  specified 
for  the  unit's  movement,  the  actual  route  to  be  traversed  is  designated  in 
the  movement  order  by  a  set  of  intermediate  coordinates  and  the  final  objec¬ 
tive  coordinates  for  the  move;  thus,  the  gamer  specifies  the  actual  route  to 
be  taken  by  the  unit  as  a  series  of  line  segments.  These  segments  are  re¬ 
ferred  to  as  order  segments  and  are  to  be  distinguished  from  the  model  move 
segments  discussed  in  subparagraph  (2)  below.  Both  types  of  segments  are 
illustrated  on  the  movement  schematic  of  Figure  IV-13-2.  If  the  route  type 
specified  in  the  travel  mode  mnemonic  is  by  road,  the  gamer-generated  order 
segments  are  to  be  chosen  such  that  the  straight  line  segments  approximate 
road  routes  actually  available  to  the  unit.  In  the  model's  computation  of 
road  movements  a  factor  of  10  percent  is  automatically  added  to  the  straight- 
line  distance  to  allow  for  a  representation  of  the  actual  minor  deviations 
from  a  straight  line  experienced  on  most  roads.  (This  subject  is  discussed 
in  the  move  rate  determination  routine,  MOVEDT).  In  road  movement,  as  well 
as  in  other  unit  movement,  the  DSL  movement  parameters  in  the  DSL  order  must 
be  carefully  chosen  to  realistically  represent  the  terrain  environment  of  the 
unit  as  derived  from  a  detailed  map  study  of  the  travel  routes  designated. 

(c)  Unit  Time  of  Departure.  The  scheduled  time  at  which  the 
model  commences  to  move  the  unit  is  implied  in  the  DSL  order  string.  In  the 
example,  the  preceding  stay  order  for  the  unit  established  the  departure  time 
as  0800  or,  equivalently  in  the  model,  the  completion  time  of  the  unit's  stay 
activity. 

(2)  Model  Move  Segments.  Within  the  Movement  Model,  dynamic 
relocation  of  a  unit  is  accomplished  in  discrete  model  move  segments.  The 
model  move  segments  are  determined  by  the  location  of  the  unit  with  respect 
to  endpoints  of  the  order  segment,  the  Doundaries  of  terrain  cells,  and  the 
locations  of  barriers  in  the  path  of  the  moving  unit.  Although  units  will 
always  complete  a  model  move  segment,  it  is  possible  for  a  unit  not  to  complete 
an  order  segment  and  to  stop  en  route  to  the  desired  objective.  The  termina¬ 
tion  of  model  move  segments  at  terrain  cell  boundaries  allows  the  unit's 
movement  rate  to  be  adjusted  to  represent  unit  mobility  response  to  changing 
terrain  features.  In  the  case  of  a  barrier,  if  the  unit's  route  will  cause 
the  unit  to  encounter  the  barrier,  the  endpoint  of  a  model  move  segment  is 
determined  by  the  location  of  the  barrier.  The  effect  of  the  barrier  on  the 
unit's  movement  is  assessed  as  discussed  in  the  specifications  for  routine 
MOVES R. 


(3)  Unit  Movement  Rates.  To  represent  unit  movement  rates  along  the 
DSL  ordered  routes,  the  model  requires  two  sets  of  rate  tables:  the  unit  type 
designator  (UTD)  normal  rate  tables  for  road  and  cross  country  movement  and 
the  mobility  class  rate  tables  for  road  and  cross  country  movement.  Botn  sets 
of  tables  are  developed  in  the  pregame  data  preparation  phase  in  accordance 
with  the  procedure  described  in  Appendix  A  to  this  Chapter.  The  rates  in 
these  tables  are  representative  rates  for  the  various  terrain,  weather,  and 
light  conditions.  Briefly,  the  mobility  class  rates  are  intended  to  represent 
short-term  characteristic  vehicle  rates  under  the  specified  conditions,  while 
the  UTD  normal  rates  reflect  unit  movement  for  given  situations,  formations,  and 


IV- 13- 7 


environmental  conditions.  The  UTD  normal  rates  are  representative  of  long¬ 
term  or  sustained  rates  to  be  expected  under  the  existing  circumstances, 
representing  standard  or  planning  rates.  These  rates  are  discussed  in  greater 
detail  in  the  specifications  of  the  move  rate  determination  routine,  MOVEDT. 

Once  the  rate  of  the  unit  is  established  for  the  segment,  it  is  combined  with 
the  length  of  the  segment  to  compute  the  required  time  for  the  unit  to  complete 
the  movement  along  the  model  segment.  This  time  is  then  used  in  the  event 
sequencing  structure  of  the  DIVWAG  system  to  effect  the  timing  of  the  dynamic 
performance  of  the  move  and  subsequent  updating  of  the  unit  location  on  the 
terrain  cell  grid. 

(4)  Movement  Model  Interfaces  with  Other  Models.  The  Movement  Model 
provides  the  Combat  Service  Support  Model  and  the  Ground  Combat  Model  with 
rates  for  generating  automatic  movement  internal  to  these  models.  It  inter¬ 
faces  the  system  Environment  Model,  using  weather,  terrain,  and  light  conditions 
to  establish  the  appropriate  move  rates.  An  interface  is  also  effected  with 
the  Area  Fire  and  Air  Ground  Engagement  Models  when  casualties  due  to  indirect 
or  aerial  fires  are  assessed  and  the  unit's  movement  is  interupted.  The 
detection  of  moving  units  by  the  Intelligence  and  Control  Model  is  triggered 
by  initiation  of  each  move  segment.  The  Engineer  Model  provides  all  barrier 
information  for  the  Movement  Model. 

(a)  Ground  Combat  Model  Interface.  Movement  within  the  Ground 
Combat  Model  represents  cross  country  ground  maneuver  movement  in  a  deployed 
formation  while  in  contact  with  the  enemy.  To  accomplish  this  movement,  the 
Ground  Combat  Model  requires  the  vehicular  mobility  class  rates  used  within 
the  Movement  Model.  The  specific  use  of  these  rates  is  described  in  Chapter 
7  of  this  section.  The  Movement  Model  initiates  a  ground  combat  engagement 
when  an  advancing  attacker  comes  within  range  of  an  opposing  unit,  which  has 
been  predesignated  within  a  DSL  battle  scenario. 

(b)  Combat  Service  Support  Model  Interface.  To  develop  resupply 
schedules  and  to  represent  the  movement  of  logistical  vehicles,  the  Combat 
Service  Support  Model  accesses  the  vehicular  movement  rate  tables  provided 

in  the  Movement  Model.  Details  are  specified  in  Chapter  16  of  this  section. 

(c)  Environment  Model  Interface.  To  determine  rates  representative 
of  environmental  conditions  the  Movement  Model  uses  weather,  terrain,  and 
light  conditions  supplied  by  the  Environment  Models  to  locate  the  correct 

rates  in  the  movement  rate  tables.  The  rate  tables  are  prepared  pregame 
and  include  consideration  of  all  possible  environmental  conditions  that  might 
be  encountered  during  the  game  period.  The  specific  parameters  and  their 
use  are  .described  in  detail  in  the  specifications  of  routine  MOVEDT. 

(d)  Engineer  Model  Interface.  A  routine  of  the  Engineer  Model 
is  interrogated  to  determine  if  a  move  segment  intersects  a  barrier  line.  If 
it  does,  the  Engineer  Model  also  provides  other  information  about  the  barrier, 
which  may  allow  the  unit  to  be  routed  around  the  barrier  or  to  an  existing 
facility.  If  such  rerouting  is  not  feasible,  the  information  is  used  to  decide 
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whether  to  force  the  barrier  or  to  request  the  Engineer  Model  to  construct  a 
facility  (breach  or  bridge)  at  that  point. 

(e)  Nuclear  Assessment  Model  Interface.  Craters  and  radiation 
resulting  from  nuclear  detonations  serve  as  barriers  to  unit  mobility.  If 
the  Movement  Model  is  informed  that  a  unit's  move  segment  will  intersect  a 
nuclear  barrier,  additional  information  is  obtained  from  the  Nuclear  Assess¬ 
ment  Model.  This  information  allows  the  Movement  Model  to  determine  if  the 
unit  should  bypass  the  barrier  or  cross  the  barrier  and  accept  the  radiation. 

(f)  Area  Fire  Model  and  Air  Ground  Engagement  Model  Interfaces. 
Target  coverage  calculations  within  the  Area  Fire  Model  are  synchronized  with 
Movement  Model  move  segment  determination  so  that  the  location  of  a  moving  unit 
at  the  time  of  impact  is  correctly  projected  for  use  in  assessing  the  effects 
of  each  area  fire  volley.  Details  of  the  target  coverage  calculation  are  con¬ 
tained  in  Chapter  8. 

(g)  Suppression  Model  Interface.  Both  the  Area  Fire  and  Air 
Ground  Engagement  Models  set  up  an  activity  suppression  event  that  causes 
a  unit's  movement  to  be  interrupted  when  it  receives  fire.  A  detailed 
explanation  of  the  modeling  of  suppression  is  contained  in  Chapter  11. 

(h)  Intelligence  and  Control  Model  Interface.  The  movement 
event  scheduling  routine  calls  the  conditional  collection  of  moving  targets 
routine  to  determine  if  any  stationary  sensor  is  in  a  position  to  detect  the 
moving  unit  during  the  current  model  move  segment. 

3.  SUBMODEL  SPECIFICATIONS: 

a.  General.  Each  of  the  three  movement  submodels  is  discussed  in  the 
following  subparagraphs.  Together,  they  represent  the  Movement  Model's 
response  to  gamer  orders.  The  model  Move  Segment  Determination  and  Coordination 
Submodel  (routine  MOVESR)  interfaces  unit  movement  activity  into  the  DIVWAG 
system  consistent  with  other  unit  military  activities  represented  by  other 
models.  The  Movement  Rate  Determination  Submodel  (routine  MOVEDT)  establishes 
typical  unit  rates  and  provides  the  MOVESR  Submodel  with  time  sequencing  infor¬ 
mation  for  the  proper  coordination  of  unit  movement  events.  Each  arrival  at 

the  endpoint  of  a  model  move  segment  is  scheduled  as  a  movement  event.  Actions 
performed  by  the  MOVE  Submodel  consist  of  updating  the  unit's  location  and 
consumables,  particularly  fuel,  when  the  arrival  at  a  model  move  segment  is 
scheduled.  The  submodels  are  described  in  the  sequence  in  which  they  operate 
in  the  system. 

b.  Model  Move  Segment  Determination  and  Coordination.  The  macroflow 
of  MOVESR  is  shown  in  Figure  IV-13-3.  Based  on  the  pending  movement  order, 
the  endpoint  of  the  next  model  move  segment  is  determiner,  and,  in  conjunction 
with  the  Move  Rate  Determination  Submodel  (MOVEDT),  the  projected  time  of 
unit  arrival  at  that  endpoint  is  calculated.  The  actual  move  event,  which  is 
arrival  at  this  endpoint,  is  then  entered  into  the  DIVWAG  event  sequencing  logic, 
as  discussed  in  Chapter  2  of  this  section. 


« 
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Figure  IV-13-3.  MOVESR  Macroflow 
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(1)  Ground  Movement.  The  model  move  segments  of  a  ground  movement 
will  have  their  endpoints  at  the  endpoints  of  order  segments,  at  terrain  cell 
boundaries,  or  at  barriers.  The  concept  is  illustrated  in  Figure  IV-13-2 
where  13  model  move  segment  endpoints  are  generated;  three  for  the  order 
segments,  one  for  the  barrier,  and  nine  for  terrain  cell  boundaries.  One  cycle 
through  each  routine  is  generally  required  for  each  model  move  segment.  As 
each  move  event  (arrival  at  an  endpoint)  is  completed,  MOVE SR  is  called  to  find 
the  next  model  move  segment's  endpoint,  and  MOVEDT  is  called  to  schedule 
arrival  time  at  that  point. 

(2)  Air  Movement.  Since  terrain  characteristics  or  ground  obstacles 
do  not  affect  air  movement,  the  model  move  segment  endpoints  are  those  of 
the  DSL  move  segments  for  air  movement.  The  DSL  fly  order  specifies  a  flight 
speed,  which  is  used  to  schedule  arrival  of  the  unit  at  move  segment  endpoints. 

(3)  Movement  Delays: 

(a)  MOVESR  automatically  schedules  a  movement  delay  if  a  unit  is 
out  of  fuel  by  generation  of  a  stay  event  of  15-minutes  duration  for  the  unit. 
Additional  15-minute  stays  are  assessed  until  the  unit  is  resupplied  with 
fuel.  This  procedure  will  cause  a  unit  to  cease  movement  when  fuel  is  ex¬ 
hausted  and  to  remain  immobile  (stay)  until  its  fuel  is  replenished  by  the 
Combat  Service  Support  Model.  When  the  unit  once  more  has  fuel,  its  movement 
is  continued  along  the  ordered  route. 

(b)  A  unit  may  be  delayed  by  barriers  as  described  in  subparagraph 

(A)  below. 

(A)  Effects  of  Barriers  and  Facilities: 

(a)  As  a  unit  begins  its  movement  along  an  ordered  move  segment, 
a  search,  using  force  intelligence  information,  is  made  to  determine  if  that 
segment  intersects  a  barrier  line  (e.g.,  river,  minefield,  forest).  If  it 

*  does,  the  unit  will  be  routed  around  the  end  of  the  barrier  line  or  to  an  ex- 

k  isting  facility,  if  either  is  sufficiently  close.  The  current  criterion  for 

nearness  is  one-half  the  sum  of  the  unit's  width  and  depth.  If  neither  an 
end  of  the  barrier  or  a  facility  is  near,  the  unit  will  continue  its  movement 
to  the  point  of  intersection. 

*  (b)  If  the  barrier  may  be  forced  (e.g.,  minefield),  a  decision 
table  is  interrogated  to  determine  if  the  unit  should  force  or  should  request 
engineering  action  and  wait  for  a  facility  to  be  constructed.  The  force/no 
force  decision  is  a  function  of  the  time  required  to  breach  the  barrier,  the 
casualties  that  would  be  assessed  if  it  is  forced,  and  the  priority  of  the 

*  move.  This  decision  table  is  part  of  the  pregame  constant  data. 
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(c)  If  the  barrier  cannot  be  forced  (e.g.,  a  river),  or  the 
decision  is  not  to  force,  the  Engineer  Model  is  requested  to  provide  a  facil¬ 
ity  at  the  point  of  intersection.  This  request  is  made  at  the  time  the  bar¬ 
rier  is  discovered  to  be  in  the  unit's  path.  When  the  unit  arrives  at  the 
site  of  construction,  it  is  given  a  stay  order  and  will  remain  in  the  stay 
mode  until  the  facility  is  complete  or  the  period  ends. 

(d)  As  the  Movement  Model  prepares  to  move  the  unit  along  each 
model  move  segment,  a  second  search  for  barriers  is  made  along  that  portion 
of  the  movement  path  with  actual  barrier  information  being  used.  This  allows 
the  effects  of  barriers  and  facilities  unknown  to  the  unit's  force  intelli¬ 
gence  to  be  modeled.  If  an  intersection  with  an  active  barrier  (e.g.,  mine¬ 
field  or  nuclear  radiation)  is  found,  casualties  will  be  assessed  the  unit 
discovering  the  barrier.  Then  the  logic  described  in  subparagraphs  (a),  (b), 
and  (c)  above  is  employed  again  to  determine  the  unit's  course  of  action. 

(e)  Unless  the  facility  provided  is  a  bridge  constructed  as 
part  of  a  roadway  and  the  unit  is  marching  on  that  road,  passing  through  the 
facility  will  temporarily  disrupt  the  formation  of  the  unit  and  will  cause 
lost  time.  The  Engineer  Model  provides  a  crossing  rate  in  terms  of  vehicles 
per  minute.  This  rate  and  a  count  of  the  vehicles  in  the  unit  allow  the  time 
lost  to  be  calculated. 

(f)  It  is  possible  that  a  unit  will  request  the  use  of  a 
facility  while  it  is  already  in  use  or  while  it  is  under  construction  and 
other  units  are  waiting  for  its  completion.  If  this  situation  occurs,  the 
unit  will  be  placed  in  a  wait  queue.  If  the  unit  has  decided  to  force  the 
barrier  and  no  engineer  activity  has  begun,  it  will  be  placed  first  in  the 
queue  and  be  allowed  to  force  immediately.  Otherwise,  the  unit  will  be  posi¬ 
tioned  in  queue  by  priority  and,  within  priority,  on  a  first-in-first-out 
basis. 


(5)  Advance  to  Ground  Combat  Engagement.  If  a  move  is  ordered  by  a 
DSL  advance  order,  MOVESR  coordinates  the  initiation  of  the  designated  battle. 
A  sample  advance  order  string  is: 

ADVANCE  TO  1162000  -  0910000. 

ENGAGE  IN  BATTLE  FOXTROT. 

MOVESR  continues  to  move  the  unit  toward  the  objective  point  in  300-meter 
move  segments.  Each  segment  is  checked  to  determine  if  the  unit  will  come 
within  3000  meters  of  an  opposing  unit  listed  in  the  scenario  of  Battle  FOX¬ 
TROT.  Upon  reaching  that  point,  the  unit  is  automatically  released  from  the 
Movement  Model  and  is  turned  over  to  the  Ground  Combat  Model  by  converting 
the  order  from  advance  to  engage.  if  a  unit  listed  in  a  battle  scenario  is 
given  a  DSL  withdraw  order,  it  is  also  moved  in  300-meter  segments  and  auto¬ 
matically  released  to  the  Ground  Combat  Model  when  the  battle  is  initiated. 
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c.  Movement  Rate  Determination  Submodel  (MOVEDT).  Unit  movement  rates 
are  established  in  the  MOVEDT.  A  macroflow  is  illustrated  in  Figure  IV-13-4, 
and  a  schematic  of  the  rate  selection  process  is  shown  in  Figure  IV-13-5. 

The  rates  available  to  the  model  are  established  in  the  pregame  data  preparation 
phase  as  illustrated  in  the  lower  left  and  right  comers  of  Figure  IV-13-5. 

The  unit's  movement  rate  is  established  by  identifying  the  nature  of  the  move 
from  the  travel  mode  mnemonic  and  by  the  prevailing  environmental  conditions. 
Using  these  parameters  the  appropriate  unit  movement  rate  tables  and  the 
mobility  class  short-term  rate  tables  are  obtained.  The  unit  is  checked  to 
ascertain  its  present  composition  in  terms  of  vehicular  mobility  classes 
and  is  not  allowed  to  exceed  the  maximum  rate  at  which  its  component  vehicles 
can  move.  If  a  delay  is  encountered  on  a  tactical  move,  the  unit  is  allowed 
to  exceed  its  standard  movement  rate  in  an  attempt  to  make  up  for  lost  time. 

The  rate  used  is  that  of  the  unit's  slowest  vehicle  not  in  an  excluded  mobility 
class.  Exclusion  of  mooility  classes  is  discussed  in  subparagraph  (2)(c),  below. 
Thus,  a  unit  executing  a  tactical  move  is  able  to  draw  from  a  reserve  mobility 
capability,  if  it  exists,  along  each  order  segment  when  required  to  do  so  by 
dynamic  events  causing  delays  for  the  unit. 

(1)  Environmental  Parameters.  The  Movement  Model  uses  selected 
environmental  parameters  as  listed  below.  (A  detailed  discussion  of  the 
Environment  Model  used  within  DIWAG  is  contained  in  Chapter  4  of  this  section. 

(a)  Road  Terrain  Factors.  The  roughness  and  vegetation  index 
of  the  Environment  Model  is  used  to  specify  two  road  terrain  factors  for  each 
terrain  cell:  terrain  I,  flat,  gently  rolling  to  undulating  (roughness  and 
vegetation  index  equals  1  to  5);  and  terrain  II,  undulating,  broken  to  rough 
(roughness  and  vegetation  index  equals  6  to  9). 

(b)  Day  and  Might.  Times  from  Beginning  of  Morning  Nautical 
Twilight  (BMN'T)  to  End  of  Evening  Nautical  Twilight  (EEXT)  are  considered 
daylight,  and  times  from  EENT  to  BMNT  are  considered  night. 

(c)  Weather.  The  weather  factors  considered  in  the  model  are 
precipitation;  none,  light,  ;r  heavy;  and  fog.  The  model  is  designed  to 
require  data  for  only  typical  summer  or  typical  winter  conditions  curing  a 
single  game.  It  is  expected  that  input  data  for  summer  and  winter  would 
differ  significantly.  The  model  assumes  fog  has  the  same  effect  as  heavy  pre¬ 
cipitation  upon  unit  movement. 

(d)  Cross  Country  Terrain  Factors.  Cross  country  movement  rates 
may  be  specified  for  up  to  20  terrain  traf ficability  indexes  as  described  in 
Chapter  4  of  this  section. 

(2)  Movement  Rate  Data.  Three  basic  groups  of  data  are  used  by  the 
Movement  Rate  Determination  Submodel:  unit  mobility  categorv  movement  rates, 
equipment  mobility  class  movement  rates,  and  equipment  mobility  class 
exclusion  tables. 

(a)  Unit  Mobility  Category  Movement  Rates.  In  the  pregame  data 
preparation  process,  type  units  are  grouped  together  into  unit  mobility 
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Figure  IV- 13-4.  MOVED T  Macroflow 
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categories.  A  unit  mobility  category  is  a  group  of  type  units,  all  of  which 
will  move  at  similar  unit  movement  rates  under  similar  conditions.  For  each 
unit  mobility  category,  a  set  of  unit  movement  rates  must  be  contained  in  the 
data  base.  These  are  the  rates  at  which  units  in  the  specified  mobility  cate¬ 
gory  will  normalLy  move  in  each  type  of  movement  to  be  defined  by  a  movement 
mode  mnemonic  [see  paragraph  2b ( 1 ) (a ) ]  under  the  set  of  environmental  condi¬ 
tions  treated  by  the  model.  Infantry  and  tank  mobility  categories  must  always 
be  defined,  as  the  movement  rates  for  these  categories  are  defaulted  to  under 
the  conditions  discussed  in  subparagraph  (3)(d)  below. 

(b)  Equipment  Mobility  Class  Movement  Rates.  In  pregame  data 
preparation,  all  ground  mobility  items  to  be  played  in  a  game  are  assigned  to 
mobility  classes,  which  group  together  items  assumed  to  have  similar  mobility 
characteristics  and,  thus,  similar  movement  rates.  A  maximum  of  20  mobility 
classes  may  be  defined  for  each  force,  with  the  first  class  reserved  for  foot 
movement.  For  each  mobility  class,  a  set  of  movement  rates  is  required,  which 
is  representative  of  maximum  rates  achievable  for  short-term  movement  (short¬ 
term  catch-up  rates).  These  rates  are  required  for  road  and  cross  country 
movement  under  the  set  of  environmental  conditions  dealt  with  in  the  model. 

(c)  Mobility  Class  Exclusion  Tables.  To  allow  for  situations 
in  which  certain  of  the  unit's  mobility  items  should  not  be  allowed  to  limit 
the  unit's  rate  of  movement  (e.g.,  reconnaissance  movement  in  which  organic 
logistic  vehicles  would  not  normally  be  used),  the  mobility  class  exclusion 
tables  identify  for  given  unit  mobility  categories  and  travel  modes  the  equip¬ 
ment  mobility  classes  not  allowed  to  limit  unit  movement.  The  foot  class  is 
used  only  as  a  default  -ate  and  need  not  be  excluded. 

(3)  Movement  Rate  Determination.  The  rate  at  which  a  unit  moves  is 
determined  by  the  travel  mode  mnemonic  of  the  DSL  order,  environmental  condi¬ 
tions  at  the  time  of  the  move,  and  the  movement  rate  data.  Generally,  the 
travel  mode  mnemonic,  the  unit's  mobility  category,  and  environmental  condi¬ 
tions  are  used  to  determine  the  unit  mobility  category  movement  rate  that 
applies.  Items  organic  to  the  unit  at  the  time  of  the  move  are  checked,  via 
the  equipment  mobility  class  movement  rate  data,  to  ensure  that  the  unit  rate 
does  not  exceed  equipment  capability.  The  mobility  class  exclusion  table  may, 
however,  override  this  check. 

(a)  Administrative  Ground  Movement.  All  DSL  orders  that  specify 
administrative  movement  use  the  standard  unit  mobility  category  rates  with  the 
mobility  class  constraints  applied  as  described  above.  The  unit's  actual  rate 
of  movement,  R^,  is  always  the  minimum  of  the  unit  mobility  category  rate,  Ry , 
and  the  limiting  equipment  mobility  class  rate,  R\;c;  i.e., 


Ra  =  MINIMUM  (Rn,  Rmc) 


(IV-13-1) 


(b)  Tactical  Ground  Movement.  '.Chen  the  DSL  order  identifies 
the  unit's  movement  type  as  tactical,  the  determination  of  the  unit's  actual 
movement  rates  requires  an  additional  check  on  the  status  of  the  unit's  move¬ 
ment  along  the  entire  DSL  segment.  The  status  is  parameterized  by  the  time 
delays  resulting  in  unit  movement  delays  that  have  occurred  during  this  DSL 
segment.  If  the  unit  is  not  operating  under  a  time  delay,  the  movement  rate. 
r.  is  established  by  Equation  IV-13-1.  If,  however,  the  unit  has  been  delayed, 
it  is  allowed  to  move  at  the  limiting  mobility  class  rate  (assuming  that  rate 
exceeds  the  unit  mobility  category  rate).  The  time  behind  schedule  or  model 
delay  parameter,  5Tl»  is  determined  from  three  sources:  i.e.,  the  obstacle 
delavs  in  MOVESR,  the  mobility  class  limits  of  MOVEDT,  and  movement  interruption 
caused  by  enemy  fire. 

1_.  If  a  unit  encounters  an  enemy  obstacle,  MOVESR  updates 
the  delay  parameter  by  adding  a  representative  delay  time,  oTdelay’  to  the 
time  behind  schedule  as: 


5T  (new)  =  jT  (old)  +  6T 

L  L  delay 


(IV-13-2) 


When  the  unit  reaches  the  endpoint  of  a  DSL  segment,  6T^  is  reset  to  zero, 
thus  providing  a  representation  of  the  nonsustainabilitv  of  the  short-term 
catch-up  rates. 


2.  The  delay  parameter  is  also  adjusted  whenever  a  unit  in 
a  tactical  move  effectively  fails  behind  schedule  because  of  limiting  mobility 
class  characteristics.  The  actual  time  delay  is  adjusted  as: 


5Tr_(naw) 


STjl  (old) 


(r-13-3) 


where : 


d 

d 


ss 


ss 


Model. 


subsegment  length  of  the  current  tactical  movement  bv  a  cross 
country  route 

(1.1)  x  (subsegment  length)  if  the  route  is  a  road  type. 

3.  The  delay  caused  by  enemy  fire  is  set  by  the  Suppression 


(c)  Road  Planning  Factor.  In  road  movement  for  both  tactical 
and  administrative  moves  the  actual  model  movement  rate  along  the  model  move 
subsegment  Is  adjusted  to  represent  the  actual  road  route  involved.  The  rate 
tables  specify  the  actual  road  rates,  but  since  the  DSL  segments  are  straight 
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line  segments,  the  model  rates  along  these  segments  need  to  be  adjusted  to 
represent  actual  road  movement.  For  road  movement  a  10  percent  road  planning 
allowance  factor  is  used  to  give  an  adi usted  model  rate,  RM, 


(IV- 13-4) 


and  the  delay  parameter,  STl,  in  Equation  IV-13-3  as  indicated.  The  road 
movement  logic  requires  the  DSL  gamer-ordered  road  movement  to  be  planned  with 
the  10  percent  road  allowance  factor  in  mind  to  represent  realistic  road 
movement  rates. 

(d)  Default  Rates.  If  the  move  combination  specified  in  the 
order  has  not  been  defined  in  the  pregame  requirements  table  of  travel  mode 
mnemonics  versus  mobility  categories,  a  default  to  the  dismounted  personnel 
rate  is  used.  If  the  DSL-ordered  travel  mode  mnemonic  is  invalid,  TCCD  is 
used.  If  the  movement  rate  table  required  by  a  particular  combination  is 
undefined,  the  movement  rate  of  heavy  tracked  vehicles  (tanks)  is  used. 

(e)  Move  Event  Time.  The  time,  aT,  to  complete  the  move  subsegment 
is  computed  in  MOVEDT  as: 

AT  =  or 

RM  rA  (IV-13-5) 


as  appropriate  and  is  used  to  set  the  move  event  time  in  MOVESR.  This  time 
is  the  only  parameter  resumed  by  the  MOVEDT  routine. 

d.  Movement  Execution  Submodel  (MOVE).  The  movement  event  scheduled  in 
MOVESR  is  actually  performed  in  MOVE.  This  routine  updates  the  unit's  actual 
coordinate  location  to  the  endpoint  of  the  model  move  segment  and  accounts  for 
consumption  of  class  III  or  class  IIIA  and  food.  A  macroflow  of  the  MOVE 
routine  is  illustrated  in  Figure  IV-13-6. 


(1)  For  moving  units,  the  total  fuel  consumption  is  determined  by: 


C 


s 


(IV-13-6) 


for  equipment  types  having  distance-dependent  consumption  rates,  and  by: 
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N 

Ct  =  -  r  t  •  A t  •  SE.  ( IV-13-7) 

j  =  l  J  J 


for  equipment  types  having  time-dependent  consumption  rates,  where: 

Cs  =  amount  of  fuel  (gallons)  consumed  by  distance-dependent  vehicles 

Cc  =  amount  of  fuel  (gallons)  consumed  by  time-dependent  vehicles 

M  =  number  of  distance-dependent  vehicle  types  in  unit 

N  =  number  of  time-dependent  vehicle  types  in  unit 

rcs^  =  fuel  consumption  rate  (gallons/meter/vehicle)  for  distance-dependent 
vehicle  i 

rct.  =  fuel  consumption  rate  (gallons/meter /vehicle)  for  time-dependent 
vehicle  j 

D  =  length  (meters)  of  subsegment 
At  =  time  (minutes)  increment 

=  number  of  distinct  items  of  equipment  for  a  given  item  code. 

(2)  Fuel  consumption  for  stationary  units  (e.g.,  idling  engines, 
generators)  is  determined  in  much  the  same  manner  except  that  all  vehicles 
have  time-dependent  fuel  consumption  rates.  The  calculation  is  as  follows: 


MN 

ct  =  I  r  '  At  •  NE-  (IV- 13-8) 

j-1  j  j 


where : 

Ct,  rct>  -it  and  are  as  previously  defined,  and 

MN  =  total  number  of  vehicle  types  in  the  unit. 

(3)  Consumption  of  food  is  recorded  continuously  for  all  simulated 
activities  within  the  DIWAG  system*  The  food  available  to  a  unit  must  be 
carried  within  the  unit's  own  supplies.  The  rate  of  consumption  is  specified 
for  a  force  in  terms  of  pounds  per  man  per  day,  but  this  value  is  converted 
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to  pounds  per  man  per  minute  at  the  time  of  execution, 
is  determined  by: 


This  consumption  value 


Cf  =  (G  +  B)  •  rcf  •  At 


(IY-13-Q) 


where : 

Cf  =  amount  (pounds)  of  food  consumed 
G  =  suppressed  (combat  ineffective)  personnel  in  the  unit 
B  =  present  effective  personnel  in  the  unit 
rcf  =  food  consumption  rate  (pounds/man/minute) 

At  =  time  (minutes)  increment  of  event. 

4.  HISTORY  TAPE  OUTPUT.  The  Movement  Model  writes  the  following  event  records 
onto  the  period  history  tape. 


Record 


Title 


Movement  Event 


Frequencj 


One  record  for  each  model 
movement  segment  scheduled. 


The  detailed  description  of  the  record  formats  is  presented  in  paragraph  2c 
of  Appendix  A  to  Chapter  1  of  Section  VI. 
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APPENDIX  A 


MOVEMENT  MODEL  INPUT  REQUIREMENTS 


1.  INTRODUCTION.  This  appendix  describes  the  movement  of  units  in  the  DIWAG 
system.  These  units  may  be  in  various  combat  formations  and  may  encounter 
various  types  of  environmental  factors,  such  as  facilities,  which  mav  speed 
the  movement  of  the  unit,  or  barriers,  which  may  delay  the  unit  or  prevent  it 
from  reaching  its  objective.  The  purpose  of  this  appendix  is  to  provide  the 
necessary  instructions  for  data  preparation  to  develop  the  constant  data  input 
needed  by  the  Movement  Model.  The  first  data  files  to  be  loaded  in  DIWAG 
are  those  for  TOE  load,  as  explained  in  Chapter  3  of  this  section.  Following 
the  loading  of  those  files,  the  constant  data  for  any  model  may  be  loaded  in 
any  order  desired. 

a.  Data  Requirements.  The  data  required  for  this  model  define  the 
mobility  characteristics  of  the  forces  being  simulated  in  the  game.  This  is 
accomplished  in  a  two-phase  data  base  developmental  process.  First,  groupings 
based  on  similar  unit  organizational  and  functional  usages  and  on  vehicular 
characteristics  are  established.  These  groupings  are  merely  a  convenience 
used  to  reduce  the  total  data  requirements  of  the  model  and  to  avoid  redun¬ 
dancy  in  the  data  preparation  process.  Secondly,  appropriate  movement  rates 
applicable  to  each  of  the  above  groups,  and  subject  to  environmental  condi¬ 
tions  and  considerations  of  unit  tactical  mission  function,  are  developed. 

Thus,  the  data  preparation  is  a  detailed  procedure  for  establishing  appro¬ 
priate  unit  categories  and  vehicular  classes  that  possess  similar  mobility 
charactersitics  and  then  assigning  realistic  movement  rates  to  each  category 
and  class.  The  dynamic  function  of  the  Movement  Model  is  to  identify  the 
extenuating  circumstnaces  existing  during  the  game  period  and  use  the  appro¬ 
priate  rates  that  were  developed  in  the  pregame  data  preparation.  The  move¬ 
ment  rates  are  used  by  the  Movement  Model  in  response  to  movement  orders, 

and  the  Ground  Combat  Model  and  the  Combat  Service  Support  Model  use  the  same 
rates  to  generate  automatic  movement  within  the  DIWAG  system. 

b.  Contents.  This  appendix  provides  detailed  instructions  in  the  data 
entry  for  constant  data  inputs  to  the  Movement  Model.  The  first  paragraph 
relates  the  preceding  instructions  to  those  pertaining  to  the  Movement  Model. 

The  second  and  succeeding  paragraphs  relate  to  the  transcribing  of  constant 
data  to  the  formats  for  the  various  cards  needed  to  enter  such  data  in  the  files 
of  the  Movement  Model.  In  each  of  these  paragraphs  a  brief  statement  is  made 
and,  where  feasible,  a  data  array  is  constructed  to  provide  an  overview  of  the 
information  required. 

c.  Data  Base  Files.  The  Movement  Model  uses  four  files  to  store  the 
constant  data  inputs.  These  files  are  illustrated  in  Figure  IV-13-A-1. 

Data  file  14  contains  the  class  IIIA  fuel  consumption  rates,  data  file  15  con¬ 
tains  the  class  III  consumption  rates,  data  file  19  contains  the  mobility 
category  movement  rates,  and  data  file  9  contains  the  mobility  categorization 
and  classification  tables.  The  mobility  load  program,  MOVELD,  creates  these 
files  from  the  card  input. 
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d.  Data  Meeded.  The  data  needed  for  the  constant  input  of  the  DIWAG 
system  consists  of  six  major  items  with  subdivisions  or  subclassifications. 

(1)  Mode  of  Travel.  The  mode  of  travel  mnemonic  is  used  in  the 
orders  specifying  ground  movement.  It  is  a  four-character  mnemonic  specify¬ 
ing  unit  movement  type,  route  type,  and  nili.ary  unit  formation.  The  various 
combinations  to  be  used  in  any  game  period  must  be  defined  and  loaded  into  the 
data  base. 

(2)  Mobility  by  Unit  Type  Designator.  All  units  that  will  be  given 
ground  movement  orders  must  be  assigned  to  a  mobility  category.  The  mobility 
category  represents  a  group  of  units  that  will  always  have  common  rates  of 
movement  for  the  same  travel  mode  mnemonic  and  environmental  conditions.  Units 
assigned  to  the  same  mobility  category  will  be  treated  as  having  identical  mo¬ 
bility  characteristics,  and  no  unit  may  be  assigned  to  more  than  one  mobility 
category. 


(3)  Equipment  Item  Mobility  Classes.  In  addition  to  the  mobility 
categories  based  on  unit  organizational  mobility  characteristics,  the  model 
requires  a  vehicular  mobility  classification  scheme  to  represent  the  mobility 
characteristics  of  mobility  items  in  the  forces,  regardless  of  the  organiza¬ 
tional  units  of  which  they  may  be  part.  Thus,  each  equipment  item  represent¬ 
ing  a  means  of  transport  must  be  assigned  to  a  mobility  class,  and  all  items 
in  the  same  mobility  class  will  be  treated  by  the  model  as  possessing  identi¬ 
cal  mobility  characteristics.  Also,  no  equipment  item  may  be  assigned  to  more 
than  one  mobility  class.  A  maximum  of  20  mobility  classes  per  force  is 
recognized  by  the  model. 

(4)  Movement  Rates.  Each  mobility  class  and  mobility  category  defined 
in  subparagraphs  (2)  and  (3)  above  must  be  accompanied  by  a  set  of  movement 
rate  tables.  For  nobility  classes,  the  rates  in  these  tables  represent  the 
short  term  or  limiting  rates  at  which  vehicles  in  the  class  can  move  subject 

to  specified  route  type,  weather,  and  terrain  conditions.  As  such,  they  form 
the  constraints  that  limit  a  unit's  movement.  For  mobility  categories,  how¬ 
ever,  the  set  of  rates  for  each  category  represents  the  normal  planning  sus¬ 
tained  rates  expected  for  the  unit  under  existing  conditions  of  route  type, 
weather,  and  terrain,  as  well  as  move  type  and  unit  formation.  Thus,  rates 
for  mobility  categories  are  based  on  organizational  and  functional  unit  move¬ 
ment  characteristics  as  well  as  environmental  parameters.  A  particular  unit 
moving  during  the  game  period  under  specified  orders  and  environmental  condi¬ 
tions  will  have  a  single  typical  mobility  category  rate  and  several  limiting 
mobility  class  rates  dependent  upon  the  dynamic  composition  of  the  unit  as 
expressed  in  terms  of  the  mobility  classes  contained  in  the  unit. 

(5)  Consumption  of  Expendables.  Unit  consumption  rates  of  fuel  are 
supplied  in  the  MOVELD  data  base. 

(6)  Breach  or  Force  Decision  Tables.  If  a  unit  executing  an  ordered 
move  event  encounters  an  active  barrier  (e.g.,  minefield)  which  it  cannot  bv-'.-.s 
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or  cross  by  means  of  an  existing  facility,  a  decision  to  force  the  barrier  or 
request  engineering  assistance  and  wait  for  a  breach  to  be  constructed  must 
be  made.  The  factors  influencing  this  decision  are  the  unit's  movement  prior¬ 
ity,  the  casualties  to  be  assessed  the  unit  if  it  chooses  to  force,  and  the 
amount  of  time  the  unit  will  be  delayed  if  it  waits  for  a  breach  to  be  con¬ 
structed.  Tables  containing  ves/no  decisions  as  a  function  of  these  factors 
must  be  prepared  and  loaded  into  the  data  base. 

2.  ASSEMBLING  THE  DATA  BASE.  The  following  subparagraphs  are  intended  to 
provide  the  user  with  a  detailed  description  of  the  contents  of  the  data  base. 
There  are  implicit  relationships  among  the  data  entries  preoared  for  the  card 
formats;  and,  thus,  proper  preparation  of  the  data  base  requires  an  understand¬ 
ing  of  these  relationships  as  they  exist  between  the  data  base,  the  orders, 
and  the  internal  functioning  of  the  Movement  Model.  The  most  important,  as 
well  as  the  most  difficult,  phase  of  the  data  base  preparation  consists  of 
identifying  mobility  categories  for  unit  structures  and  mobility  classes  for 
vehicular  equipment  contained  within  units.  Subparagraph  a  below  discusses 
this  phase  in  detail.  In  addition  to  the  categorization  and  classification 
process,  appropriate  rates  of  movements  must  be  developed.  The  parameters  to 
be  included  in  determining  these  rates  and  how  they  are  used  within  the  model 
are  discussed  in  subparagraph  b.  Subparagraph  c  summarizes  the  data  base 
preparation  process  with  a  procedure  for  developing  a  consistent  and  represen¬ 
tative  set  of  data  for  the  Movement  Model. 

a.  Mobility  Classes  and  Categories.  To  represent  unit  movement  in  a 
realistic  manner  within  the  confines  of  a  manageable  data  base  it  is  impera¬ 
tive  to  reduce  to  a  limited  number  of  parameters  the  enormous  quantity  of  de¬ 
tails  that  can  affect  movement  of  troops  and  supplies.  The  mobility  classes 
and  categories  represent  the  approach  used  in  the  DIVWAG  Movement  Model  to 
accomplish  this  and  still  retain  the  primary  mobility  characteristic  of  the 
force  involved. 

(1)  Mobility  Category.  A  mobility  category,  as  discussed  previously, 
represents  a  group  of  unit  organizational  structures  that  are  expected  to  have 
similar  mobility  characteristics.  For  example,  the  first  mobility  category  in 
the  model  is  always  reserved  for  unit  organizational  structures  that  can  be 
expected  to  move  as  a  typical  dismounted  infantry  unit.  Another  category  might 
be  typified  by  a  heavy  armor  battalion.  The  implication  is  always  that  a  unit 
belongs  to  the  mobility  category  that  best  represents  that  unit's  mobility 
characteristics  (i.e.,  rate  of  movement  under  the  specified  conditions).  The 
model  allows  up  to  20  distinct  nobility  categories  per  force.  The  categories 
are  developed  from  the  unit  type  designators  (UTDs) ,  which  were  discussed  in 
Chapter  3  of  this  section.  Since  the  allowable  number  of  distinct  unit  type 
designators  is  large,  and  since  the  unit  type  designator  is  not  meant  to  be 
representative  of  unit  mobility  characteristics,  the  mobility  categories  are 
required  to  eliminate  redundancy  and  compact  the  data  base  reouirements . 

A  unit  type  can  only  be  assigned  to  a  single  mobility  category,  but  several 
unit  types  can  belong  to  a  single  category. 
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(a)  Mobility  Category  Codes.  Each  mobility  category  is  assigned 
a  code  letter  which  appears  as  the  last  character  of  a  four-character  mnemonic. 
The  code  letters  "I"  and  "T"  are  reserved.  Other  code  letters  are  arbitrarily 
selected  by  the  user  and  assigned  to  a  particular  means  of  conveyance.  The 
infantry  category  must  have  the  letter  ”1"  as  its  category  code-  thereafter, 
for  this  constant  data  input,  the  letter  "I"  would  be  associated  with  infantry- 
units  that  move  on  foot.  The  armor  unit's  category  must  have  the  letter  "T" 
assigned  as  its  code.  "C"  might  be  assigned  for  a  cavalry  unit  categorv.  In 
this  manner  a  mobility  category  code  is  constructed.  The  table  below  is  an 
example  of  the  various  mobility  categories  mentioned  in  the  oreceding  suboara- 
graphs  and  summarized  for  clarity. 


Code 

Mobility  Category 

Unit 

Tvpe  Designator 

_I_.\'FY 

Dismounted  infantry  unit 

I  MM  I 

TANK 

Tank  armored  unit 

EAMT  , 

ITCT,  1TMT,  BTCT 

CAVY 

Cavalry  unit 

ICCC. 

ITMC 

(b)  Mobility  Category  Movement  Rates.  Every  mobility  category- 
developed  for  a  game  must  be  accompanied  by  a  set  of  movement  rates  character¬ 
istic  of  all  units  assigned  to  this  category.  These  rates  are  subject  to  the 
following  considerations: 

.  Type  movement  being  performed 

.  Type  route  being  traversed 

.  Formation  of  unit 
Weather  conditions 
.  Day  or  night  conditions 
Terrain  conditions. 

These  items  constitute  the  set  of  model  parameters  that  affect  unit  movement; 
they  are  described  in  detail  in  subparagraph  b  below.  The  rates  are  expressed 
in  kilometers  per  hour  and  must  be  developed  for  all  combinations  of  the  model 
parameters  that  may  occur  during  the  game.  The  number  of  rate  tables  required 
for  a  particular  mobility  category  is  dependent  unon  the  number  of  travel  modes 
in  which  this  category  is  allowed  to  move  as  illustrated  in  Figure  TT'-13-A-2 . 

For  example,  if  the  units  assigned  to  a  tank  mobility  categorv  are  given  a  move 
order  containing  the  travel  mode  TCCD  (tactical  cross  country  move  in  a  denloved 
formation)  a  rate  table  that  specifies  the  planning  rates  typical  for  such  a 
unit  must  be  developed.  The  rate  table  for  this  mnemonic  will  contain  120 
(3  *  2  •  20)  entries  to  represent  all  possible  combinations  of  weather  (3  types), 
light  conditions  (2  types),  and  cross  country  traf ficabilitv  conditions  (20 
types).  If  the  travel  mode  TRDM  (tactical  movement  in  a  march  column  on  a  dirt 
road)  is  also  to  be  used,  a  set  of  rates  representing  all  combinations  of  road / 
terrain  types  (2),  weather  types  (3),  and  light  conditions  (2  types),  or  12 
rate  entries,  is  required  for  the  same  tank  mobilitv  category.  The  rates  to 
be  entered  into  the  data  base  are  to  be  representative  of  typical  rates  to  be 
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expected  under  the  set  of  conditions  specified.  They  can  be  developed  in  a 
manner  analogous  to  actual  planning  operation  rates  used  in  real  situations. 

Units  in  the  model  will  move  at  these  rates  subject  to  constraints  imposed  by 
the  mobility  class  limiting  rates  discussed  in  subparagraph  (2)  below. 

(2)  Mobility  Class.  Mobility  class  always  refers  to  the  type  of 
conveyance  used  to  move  units  about  the  battlefield.  These  types  refer  to 
items  of  equipment,  which  in  the  DIWAG  system  are  identified  with  an  equipment 
item  code.  An  example  of  a  mobility  class  is  track-laving  vehicles,  in  which 
tanks  and  armored  personnel  carriers  might  be  classed.  Some  self-propelled 
artillery  and  air  defense  vehicles  might  also  come  under  the  same  class.  Also, 
a  combat  engineer  vehicle  with  M60  chassis,  a  165mm  gun,  and  50  caliber  machine- 
gun  may  be  in  the  track-laving  vehicles  mobility  class.  On  the  other  hand, 
an  engineer  bulldozer,  although  a  track-laying  vehicle,  may  not  be  assigned 
to  this  mobility  class  since  its  rate  of  sustained  or  maximum  movement,  either 
cross  country  or  on  roads,  is  slower  than  the  other  combat  items.  Another 
candidate  mobility  class  is  the  81mm  mortar,  full-tracked,  M125A1  carrier  or 
the  light-tracked,  M577,  command  post  carrier.  Since  these  types  of  conveyances 
have  relatively  the  same  rates  of  movement,  as  well  as  traf ficability  and  move¬ 
ment  capability  both  on  roads  and  cross  country,  these  lighter  tracked  vehicles 
might  be  placed  in  the  same  class.  The  same  is  true  with  wheeled  vehicles  in 
which  the  heavy  wheeled  vehicles,  such  as  10-ton  dump  trucks  and  similar  vehicles 
would  be  placed  in  a  class  different  from  that  of  a  10-ton  tractor-trailer  truck. 
The  model  reserves  mobility  class  index  1  for  the  mobility  class  tvpical  of  the 
dismounted  foot  soldier  and  allows  for  a  maximum  of  19  additional  classes.  It 
is  to  be  remembered  that  all  vehicles  assigned  to  the  same  mobility  class  will 
have  identical  mobility  characteristics.  Thus,  if  two  competing  vehicle  types 
are  to  be  distinguished  by  their  mobility  performance  parameters,  they  must 
belong  to  separate  mobility  classes.  Mobility  categories  are  representative 
of  entire  organizational  units  acting  in  concert,  and  mobility  classes  are 
representative  of  the  vehicular  components  of  that  unit. 

(a)  Mobility  Class  Codes.  Each  of  the  mobility  classes  is 
assigned  a  code  number,  with  the  number  1  being  reserved  for  dismounted  infan¬ 
try.  Thus,  the  light-tracked  vehicles  may  have  a  mobility  class  code  i  assigned. 
Code  5  might  be  assigned  to  light  wheeled  vehicles,  such  as  jeeps.  Code  2  may 
be  assigned  to  medium  wheeled  vehicles,  such  as  2-1 /2-ton  cargo  trucks,  as 

well  as  tankers  and  similar  wheeled  vehicle  types.  The  code  3  may  have  been 
assigned  to  the  heavy  wheeled  vehicles,  and  this  may  include  towed  8-inch 
howitzers,  towed  155mm  howitzers  or  guns,  and  heaw  dump  trucks  or  similar 
wheeled  vehicles.  These  indexes  are  used  internally  in  the  model  to  identify 
the  mobility  classes  present  in  a  unit. 

(b)  Mobility  Class  Movement  Rates.  Whereas  the  mobility  categorv 
rates  are  representative  of  organizational  units  as  a  whole,  the  mobility 
class  rates  do  not  represent  any  specific  organizational  structure  and,  as 
such,  are  not  dependent  upon  the  type  of  move  or  unit  formation  parameters  dis¬ 
cussed  below.  The  parameters  applicable  to  developing  mobility  class  rates 
are  the  following: 


IV-13-A-7 


tWWKMMWS*  f* ' 


.  Type  of  route  being  traversed 
.  Weather  conditions 
.  Day  or  night  conditions 
.  Terrain  conditions 

As  such,  mobility  class  rates  are  more  representative  of  the  performanc. 
characteristics  of  individual  vehicles.  Unit  movement  is  restricted  tc  the 
speed  of  its  slowest  vehicle  if  unit  integrity  is  to  be  maintained  during  the 
movement.  This  restriction  is  used  in  the  model  with  reference  to  the  mobility 
classes  contained  in  the  unit.  The  model  will  always  imnose  this  restriction 
to  unit  movement  (subject  to  modification  by  the  mobility  class  exclusion 
table)  and  will  check  compositions  of  units  to  ensure  that  the  rate  of  move¬ 
ment  of  the  slowest  mobility  class  present  is  not  exceeded.  The  Mobility 
Model  uses  the  mobility  class  rates  in  a  manner  analogous  to  a  short-term 
catch-up  rate  (i.e.,  a  mobility  class  can  achieve  this  rate  for  a  short 
period  of  time  but  cannot  sustain  this  rate  on  a  long  move).  Each  mobility 
class  defined  requires  36  road  rates  (3  •  2  •  3  •  2)  and  120  cross  country 
rates  (1  •  20  •  3  •  2)  to  represent  vehicular  characteristics  subject  to  route 
(1  cross  country  type  or  3  road  types) ,  terrain  conditions  (2  road  types  or  20 
cross  country  types),  weather  conditions  (3  types),  and  light  conditions  (2 
types) . 


(c)  Mobility  Class  Exclusion  Table.  To  identify  vehicles  that 
are  not  considered  as  moving  with  the  parent  unit  and  thus  not  immediatelv 
restricting  a  unit's  movement,  a  mobility  class  exclusion  table  is  reauired. 
For  example,  an  armor  battalion,  prior  to  taking  a  combat  position  mav  have 
sent  its  trains  back  to  join  the  brigade.  Thus,  when  the  armor  battalion 
moves  in  a  cross  country  deployed  formation,  the  supply  train  vehicles  are 
not  contained  in  the  formation  and  will  not  impede  the  movement  rate  of  the 
battalion.  The  exclusion  table  allows  the  mobility  class  representing  the 
supply  train  vehicles  to  be  excluded  from  consideration  in  restricting  the 
armor  battalion. 

b.  Model  Parameters  Influencing  Unit  Movement.  The  model  parameters  that 
influence  the  movement  rate  of  units  have  already  been  identified  in  the  sub- 
paragraphs  discussing  mobility  category  rates  and  mobility  class  rates.  They 
are  repeated  for  emphasis: 

.  Movement  type 
.  Route  type 
.  Unit  formation 
.  Weather  conditions 
.  Day  or  night  conditions 
.  Terrain  conditions 
.  Movement  priorities 


The  first  three  move  parameters — movement  type,  route  type,  and  formation  of 
unit — are  always  contained  in  the  order  and,  as  such,  convey  gamer  planning 
and  coordination  information.  They  are  specified  in  the  travel  mode  mnemonic. 
The  next  three  parameters — weather  conditions,  light  conditions,  and  terrain 
conditions — are  established  by  the  DIVWAG  Environmental  Model  and  establish 
the  environmental  conditions  existing  during  dynamic  game  play.  The  last 
parameter — movement  priorities — also  contained  in  the  order,  indicates  the 
importance  of  the  unit’s  movement  and  establishes  its  priority. 

(1)  Travel  Mode  Mnemonic.  The  travel  mode  mnemonic  is  a  four- 
character  code  containing  movement  type,  route  type,  and  unit  formation  type 
information.  The  model  recognizes  only  those  combinations  defined  in  the  data 
preparation,  and  these  combinations  must  be  developed  from  the  movement  tvpes, 
route  types,  and  unit  formation  types  discussed  in  following  subparagraphs. 

The  travel  mode  mnemonic  ij  specified  in  DSL-directed  moves.  One  exception  is 
that  units  that  are  to  travel  cross  country  in  a  deployed  formation  (TCCD)  do 
not  require  the  mnemonic.  This  particular  method  and  formation  is  also  used 
as  the  default  travel  mode;  that  is,  any  unit  ordered  to  move,  but  not  given 
a  specific  travel  mode  mnemonic,  will  travel  cross  country  in  a  deployed  for¬ 
mation.  Through  the  travel  mode  the  gamer  may  directly  influence  the  rate  at 
which  the  various  units  will  move.  Thus,  the  preparation  of  realistic  move¬ 
ment  orders  consistent  with  the  travel  modes  and  rates  developed  in  the  data 
preparation  phase  is  essential  for  a  realistic  performance  of  the  move.  In 
addition,  the  definitions  of  the  move  type,  route  type,  and  unit  formations 
should  be  increased  in  detail  and  clarity  if  necessary  to  ensure  that  the 
travel  mode  mnemonic  and  implied  movement  rates  are  consistent  with  the 
military  intent  of  those  using  the  model. 

(a)  Movement  Type.  The  type  of  unit  movement  planned  is 
restricted  by  the  model  to  include  two  categories,  administrative  and 
tactical: 


.  A  -  Administrative:  This  category  implies  movement  of 
units  by  road  nets  and  uses  the  most  efficient 
transportation  systems  available,  with  tactical 
considerations  of  secondarv  importance. 

.  T  -  Tactical:  Movement  of  this  type  includes  cross 

country  movement  in  partially  deployed,  reconnais¬ 
sance,  or  column  march  formations,  and  tactical 
road  marches  as  part  of  an  attack,  withdrawal,  or 
other  tactical  plan  external  to  maneuver  movement 
within  the  ground  combat  engagements. 

(b)  Route  Type.  The  route  tyoe  must  also  be  defined  prior  to 
developing  travel  mode  combinations  and  actual  movement  rates.  Available 
types  are  listed  below.  These  types  are  fixed  by  the  model  hut  should  be 
defined  in  greater  detail  in  relation  to  the  actual  routes  planned  for  the 
game  to  ensure  gamer  consistency  in  their  usage.  These  route  type  descriptors 
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specify  the  type  of  ground  surface  that  the  unit  will  be  moving  on  in  an 
order.  These  descriptors  are: 

CC  -  Cross  Country:  Route  of  the  unit  is  subject  to 

natural  terrain  conditions  existing  in  its  path. 

RA  -  Paved  Roads:  This  route  type  is  such  that  road  beds 
are  asphalt  or  concrete  with  at  least  two  lanes 
with  good  shoulders,  and  the  route  is  not  signifi¬ 
cantly  dependent  upon  short  range  or  local  terrain 
features. 

.  RG  -  Gravel  Roads:  Route  is  gravel  or  similar  surfaced 
road  with  periodic  maintenance. 

.  RD  -  Dirt  Roads:  Route  is  dirt,  road  is  narrow  and/or 
marginally  maintained  and  is  subject  to  terrain 
undulations  and  other  local  terrain  features. 

(c)  Unit  Formation.  The  last  character  of  the  travel  mode 
specifies  the  unit's  move  formation  for  the  current  move.  Three  types  are 
available  in  the  model;  and,  as  with  the  route  and  move  types,  the  definitions 
given  below  can  be  enriched  better  to  define  the  existing  conditions  intended 
in  using  this  parameter.  For  example,  a  unit  may  be  much  more  cautious  in 
approaching  the  vicinity  of  hostile  forces  than  it  would  in  marching  through 
friendly  terrain.  The  fact  that  the  enemy  force  is  near  has  an  influence  in 
reducing  speed  of  movement.  In  the  case  of  the  unit  oassing  through  friendly 
territory  and  on  its  way  to  an  assembly  area  for  a  battle  several  days  hence, 
the  formation  may  be  a  march  column;  however,  that  unit  about  to  make  contact 
with  the  enemy  is  probably  in  a  deployed  formation  or  reconnaissance  formation 
Available  formations  are  the  following: 

.  M  -  Column  March:  The  unit  is  in  a  column  formation  on  a 
road  or  cross  country  route. 

.  R  -  Reconnaissance:  Deployment  pattern  on  cross  country 
by  a  unit  on  a  ground  reconnaissance  type  mission. 

.  D  -  Deployed:  Unit  is  partially  deployed  in  a  formation 
in  anticipation  of  imminent  contact  with  the  enemy. 

(2)  Allowable  Modes  of  Travel.  The  allowable  combinations  of  move 
type,  route  type, and  formation  type  are  defined  in  the  pregame  data  load.  A 
maximum  of  20  combinations  is  allowed.  A  typical  group  required  for  a  game 
might  be  as  follows: 
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Code 

ARAM 

ARGM 

TRAM 

TRGM 

TRDM 

TRGR 

TCCM 

TCCR 

TCCD 


Move.  Route  and  Formation  Defined 

Administrative  move  on  all  weather  roads  in  march  column 

Administrative  move  on  gravel  roads  in  march  column 

Tactical  move  on  improved  paved  roads  in  march  column 

Tactical  move  on  improved,  gravel,  or  other  similar 
surfaced  roads  in  march  column 

Tactical  move  on  unpaved  or  dirt  roads  in  march  column 

Tactical  move  on  improved,  gravel  roads  in  reconnaissance 
formation 

Tactical  cross  country  move  in  march  column 

Tactical  cross  country  move  in  reconnaissance  formation 

Tactical  cross  country  move  in  deployed  formation 


(3)  Environmental  Consideration.  The  weather  and  terrain  always 
influence  the  rate  of  military  movements  over  any  type  of  surface.  For  the 
Movement  Model  these  parameters  are  defined  in  the  DIVVAG  Environmental  Model, 
but  for  purposes  of  preparing  the  move  rate  tables  it  is  necessary  to  obtain 
descriptions  of  these  parameters  before  considering  the  actual  rates  involved. 
Thus,  the  following  factors  should  be  used  in  determining  the  appropriate 
rates  for  the  rate  tables. 

(a)  Road  Terrain  Factors.  Road  terrain  factors  are  derived 

from  the  roughness  and  vegetation  index  specified  for  each  terrain  cell  in  the 
data  load.  The  categorizations  used  in  the  Movement  Model  are  as  follows: 

.  T]_  -  Terrain  1:  Flat,  gently  rolling  to  undulating. 

Roughness  and  vegetation  indexes  1  through  5. 

.  T2  -  Terrain  2:  Undulating,  broken  to  rough.  Roughness 
and  vegetation  indexes  6  through  b. 

(b)  Day  and  Night  Conditions.  Day  and  night  conditions  are 
derived  from  the  Environment  Model  and  are  such  that  the  rate  tables  reflect 
the  following  typical  conditions: 

.  D  -  Day:  Daylight  hours,  beginning  of  morning  nautical 

twilight  (BMNT)  to  end  of  evening  nautical  twilight 
(EENT) . 
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M  -  Night:  EENT  to  3MNT  with  light  levels  typical  of 
quarter  moon. 


(c)  Weather  Conditions.  Weather  factors  considered  in  filling 
out  the  rate  tables  are  defined  in  the  following  manner: 


W1  -  Weather  1:  Temperature  greater  than  32°r,  no  rain; 
or  temperature  less  than  32°F,  no  rain  or  snow. 

W2  -  Weather  2:  Temperature  greater  than  32°F,  light  rain 
or  temperature  less  than  32°F,  light  rain  or  snow. 

N3  -  Weather  3:  Temperature  greater  than  32°F,  heavy  rain 
or  fog;  or  temperature  less  than  32°F,  heavy  rain 
or  snow. 


The  model  is  designed  to  include  only  typical  winter  or  typical  summer  condi¬ 
tions  during  a  single  game.  Either  the  first  set  or  the  second  set  is  chosen, 
and  appropriate  rate  tables  are  filled  out  accordingly. 

(d)  Cross  Country  Terrain  Factors.  The  cross  country  travel  mode 
uses  up  to  20  combinations  of  terrain,  soil,  and  forest  types.  A  typical  cate 
gorization  of  these  soil  slope,  and  traf ficability  indices,  Ti  through  T20>  is 
as  follows: 


T|  -  Flat  to  gently  rolling,  coarse-grained,  poorly  graded 
sand  and  silt  with  clay  layer,  forested. 

T2  -  Flat  to  gently  rolling,  coarse-grained,  poorly  graded 
sand  and  silt  with  clay  layer,  not  forested. 


T3  -  Flat  to  gently  rolling,  silt  over  clay  type  sand  and 
sandy  clay,  forested. 

T4  -  Flat  to  gently  rolling,  silt  over  clay  type  sand  and 
sandy  clay,  not  forested. 

T5  -  Gently  rolling  to  undulating,  coarse-grained,  poorly 
graded  sand  and  silt  with  clay  layer,  forested. 


T6 


Gently  rolling  to 
graded  sand  and 


undulating,  coarse-grained,  poorly 
silt  with  clay  layer,  not  forested. 


T7  -  Gently  rolling  to  undulating,  silt  over  clay  type  sand 
and  sandy  clay,  forested. 


T8 


Gently  rolling  to 
and  sandy  clay. 


undulating,  silt  over  clay  type  sand 
not  forested. 
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T9  -  Undulating  to  broken,  coarse-grained,  poorly  graded  sand 
and  silt  with  clay  layer,  forested. 

Tj_Q  -  Undulating  to  broken,  coarse-grained,  ooorlv  graded  sand 
and  silt  with  clay  layer,  not  forested. 

Til  _  Undulating  to  broken,  silt  over  clay  type  sand  and  sandv 
clay,  forested. 

Tl2  -  Undulating  to  broken,  silt  over  clay  type  sand  and  sandy 
clay,  not  forested. 

Tl3  -  Broken  to  rough,  coarse-grained,  poorly  graded  sand  and 
silt  with  clay  layer,  forested. 

Tl4  -  3roken  to  rough,  coarse-grained,  poorly  graded  sand  and 
silt  with  clay  layer,  not  forested. 

T^5  -  3roken  to  rough,  silt  over  clay  type  sand  and  sandy  clay, 
forested. 

Tifc  -  Broken  to  rough,  silt  over  clay  type  sand  ind  sandy  clay, 
not  forested. 

Tl7  -  Rough  terrain,  coarse-grained,  poorly  graded  sand  and 
silt  with  clay  layer,  forested. 

Tl8  -  Rough  terrain,  coarse-grained,  ooorly  graded  sand  and 
silt  with  clay  layer,  not  forested. 

1^9  -  Rough  terrain,  silt  over  clay  type  sand  and  sandy  clay, 
forested . 

T20  “  Rough  terrain,  silt  over  clay  tyoe  sand  and  sandy  clay, 
not  forested. 

(4)  Movement  Priorities.  A  unit's  movement  priority  affects  its 
decision  to  breach  or  force  an  active  barrier,  if  one  is  encountered,  and  is 
also  used  to  determine  the  priority  of  any  engineering  task  this  unit  might 
find  necessary  to  request.  Four  priorities  are  defined  below.  The  limitation 
of  four  priorities  is  arbitrary  as  are  the  definitions.  A  maximum  of  six  pri¬ 
orities  may  be  defined  in  comoiling  the  data. 

Priority  1.  This  priority  is  the  highest.  It  would  be  given 
units  if  their  completion  of  a  move  on  time  is  essential  to 
the  success  of  the  division's  maneuver. 

.  Priority  2:  Successful  completion  of  moves  given  this  priorit 
would  greatly  facilitate  the  operation,  but  it  would  not 
collapse  without  it. 
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Priority  3:  Successful  completion  of  moves  in  this  priority 
is  desirable,  but  would  effect  the  operation  to  a  lesser 
degree. 

.  Priority  4:  This  priority  is  the  lowest  and  would  be  defaulted 
to  if  a  priority  is  not  specified  by  the  priority  modifier. 
Routine  maneuvers  fall  into  this  class. 

c.  Recommended  Data  Base  Preparation  Procedures.  The  following  Drocedure 
is  described  as  an  example  of  a  systematic  approach  that  might  be  used  to  de¬ 
velop  the  Movement  Model  data  base.  The  procedure  is  not  a  fixed  set  of  inde¬ 
pendent  steps  that  may  be  separately  performed  but  is  a  logical  process  whereby 
a  comprehensive  overview  of  the  model's  structure  can  be  obtained  as  well  as 
an  understanding  of  the  detailed  data  requirements.  Figure  IV-13-A-3 
illustrates  the  data  base  preparation  orocess. 

(1)  Step  1.  Standardize  the  definitions  of  the  weather  types  and 
terrain  conditions  to  ensure  that  the  definitions  used  for  the  Movement  Model 
parameters  are  consistent  with  the  environmental  parameters  (e.g..  terrain, 
cell,  soil,  slope  and  traf f icability)  prepared  for  the  environmental  load  pro¬ 
grams.  For  example,  the  soil,  slope  and  traf f icability  conditions  defined  in 
the  terrain  cell  load  data  should  be  identical  to  the  definition  used  in  the 
Movement  Model  data  preparation. 

(2)  Step  2.  Establish  game  definitions  of  what  conditions  will  be 
implied  by  the  gamer  usage  of  the  travel  mode  mnemonic  specifying  move  types, 
route  types,  and  formation  types.  It  is  essential  that  the  gamer  in  writing 
movement  orders  have  a  clear  understanding  of  the  conditions  and  corresponding 
movement  rates  implied  by  the  travel  mode  mnemonic. 

(3)  Step  3.  Classify  all  mobility  vehicles  to  be  used  by  a  force 
into  mobility  classes  and  determine  mobility  class  rates  in  the  following 
manner : 


(a)  Step  3a.  Choose  a  particular  vehicle  that  is  expected  to  be 
typical  of  a  mobility  class  and  assign  this  vehicle  to  a  mobility  class  and 
define  the  mobility  class. 

(b)  Step  3b.  Develop  a  movement  rate  table  to  describe  the  short 
term  sustained  rates  of  this  type  vehicle  subject  to  road  or  cross  countrv  ter¬ 
rain  conditions,  weather  conditions,  and  light  conditions  that  have  been 
defined  in  steps  1  and  2. 

(c)  Step  3c.  Scan  the  list  of  mobility  vehicles  that  have  not 
yet  been  classified  and  select  one  that  may  also  belong  to  this  same  mobility 
class.  Consider  the  rate  table  that  was  filled  out  for  the  mobility  class  be¬ 
ing  developed  and  decide  if  the  vehicle  being  considered  will  have  the  same 
rates  previously  entered  into  the  rate  table.  If  this  is  the  case,  assign  this 
vehicle  to  the  same  mobility  class.  If  this  is  not  the  case,  scan  the  list  for 
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a  different  vehicle  and  repeat  the  process  until  all  vehicles  belonging  to 
this  mobility  class  have  been  identified. 

(d)  Step  3d.  When  all  vehicles  belonging  to  a  mobility  class 
have  been  defined  select  a  typical  vehicle  characteristic  of  another  mobility 
class  and  repeat  the  process.  Continue  in  this  manner  until  all  vehicular 
mobility  items  have  been  classified. 

(4)  Step  4.  Categorize  all  unit  type  designators  (UTDs)  into 
mobility  categories  and  establish  mobility  category  rates  in  the  following 
manner : 


(a)  Step  4a.  Select  a  unit  type  designator  that  is  considered 
a  typical  example  of  a  particular  mobility  category. 

(b)  Step  4b.  List  all  travel  mode  mnemonic  combinations  needed 
in  the  game  to  represent  movement  of  this  typical  unit. 

(c)  Step  4c.  For  each  travel  mode  selected,  complete  the 
appropriate  mobility  category  rate  table. 

(d)  Step  4d.  Select  another  UTD  type  and  repeat  steD  4b.  For 
travel  modes  already  allowed  for  this  category,  check  the  UTD  type  being  con¬ 
sidered  to  ensure  that  the  rates  are  consistent.  For  travel  modes  not  already 
included,  develop  a  set  of  rate  tables  as  in  step  4c. 

(e)  Step  4e.  Continue  the  selection  of  UTD  types  until  all  UTDs 
belonging  to  this  category  have  been  considered. 

(f)  Step  4f.  When  one  category  is  completed,  repeat  steps  4a 
through  4e  for  the  next  category.  Continue  in  this  fashion  until  all  UTDs  to 
be  used  in  the  game  have  been  categorized  and  the  corresponding  rate  tables 
are  developed.  The  performance  of  step  4  culminates  with  the  completion  of 
the  matrix  of  movement  modes  and  mobility  categories  (Figure  IV-13-A-2)  and  is 
a  summary  of  the  categories,  travel  modes,  and  allowed  combinations  developed 
in  the  data  base. 

(5)  Step  5.  The  fifth  step  in  defining  the  data  base  is  to  consider 
each  unit  type  designator  with  every  allowed  travel  mode  and  to  specify  those 
nobility  classes  normally  contained  in  the  type  unit  TOE  that  will  not  be  per¬ 
mitted  to  limit  the  unit's  rate  of  movement  under  the  conditions  specified  in 
the  ..ravel  mode.  This  required  step  allows  the  model  to  realistically  identify 
unit  supply  trains,  bridging  equipment,  etc.,  that  are  not  limiting  mobility 
factors  in  the  unit's  current  mission  objective. 

(6)  Step  6.  Develop  appropriate  fuel  consumption  rates  for  vehicles 
and  aircraft  equipment  items. 

(7)  Step  7.  Develop  barrier  decision  table.  If  a  unit  under  control 
of  the  Movement  Model  must  cross  an  active  barrier,  a  decision  table  is  in¬ 
terrogated  to  decide  if  the  unit  should  accept  casualties  and  force 
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the  barrier  or  accept  the  time  delay  and  wait  for  a  breach  to  be  constructed. 
One  table  is  required  for  each  movement  priority  used  during  the  game.  A 
maximum  of  six  tables  may  be  used,  but  at  least  one  table  must  be  used.  The 
decision  tables  are  independent  of  the  unit's  mobility  category  and  other 
data  necessarv  for  the  Movement  Model.  A  sample  decision  table  for  a  prioritv 
is  shown  in  Figure  IV-13-A-4.  The  times  shown  are  fixed  and  cannot  be  changed, 
but  the  number  of  casualties  applying  to  each  column  is  arbitrary  and  is  out 
on  the  data  form. 
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Figure  IV-13-A-4.  Example  of  Breach  or  Force  Decision  Table 


(a)  Step  7a.  Determine  the  number  of  priorities  that  will  be 
used  during  the  game  and  agree  upon  a  written  description  of  each  priority. 
One  decision  table  will  be  required  for  each  priority  used. 

(b)  Step  7b.  Construct  a  work  form  similar  to  Figure  IV-13-A-4 
for  each  table. 

(c)  Step  7c.  Comolete  the  form  for  each  table  using  the  number 
1  to  indicate  the  unit  should  wait  for  a  breach  to  be  constructed  or  2  to 
indicate  the  unit  should  force  the  barrier. 
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3.  TRAVEL  MODE  AND  MOBILITY  CATEGORY.  The  travel  node  and  nobility  category 
are  specified  on  card  type  1  with  ID  of  1401.  The  information  desired  is  the 
various  nodes  of  travel  correlated  to  the  nobility  category.  This  is  the 
first  card  to  be  entered  in  the  data  base  as  a  rigidly  structured  data  deck. 

a.  Travel  Mode  and  Mobility  Categories.  The  nodel  recognizes  two 
categories  of  movement,  administrative  and  tactical.  Each  of  these  movement 
types  is  associated  with  the  rate  of  movement  and  the  environmental  conditions 
found  in  combat.  The  explanation  of  the  two  movements  recognized  by  the  sub¬ 
model  follows. 

(1)  Administrative  (A).  Employing  movement  of  units  by  road  nets  or 
by  air  using  the  most  efficient  transportation  system  available.  This  move¬ 
ment  is  to  be  conducted  over  all  weather  paved  roads  or  improved  roads  but  not 
all  weather  gravel  or  similar  type  surfaced  roads. 

(2)  Tactical  (T) .  In  this  category  are  included  cross  country  ground 
formations  of  partially  deployed,  reconnaissance,  or  column  march.  Also  in¬ 
cluded  are  tactical  road  marches  as  part  of  an  attack,  withdrawal,  or  other 
tactical  plan  external  to  the  Movement  Model. 

b.  Route  Type.  The  route  type  as  previously  discussed  is  an  indication, 
for  the  model,  of  the  movement  with  respect  to  the  soecific  ground  oath  that 
a  unit  will  take  to  its  destination  from  its  present  position.  These  route 
descriptors  merely  specify  the  type  of  surface  that  the  unit  will  use  in  mov¬ 
ing  to  its  objective.  These  descriptors  are: 

(1)  Cross  Country  (CC).  Route  of  unit  is  subject  to  natural  terrain 
and  environmental  conditions  including  soil  of  different  or  varying  traffic- 
ability.  Speed  is  somewhat  dependent  on  weather  for  day  or  night  movement 
including  clear  and  inclement  weather. 

(2)  Paved  Roads  (RA) .  The  path  used  by  the  unit  will  be  over  a 
roadbed  of  asphalt,  concrete,  or  other  hard  surfaced  material  used  for  road¬ 
ways.  These  roads  have  at  least  two  lanes  with  good  shoulders,  and  movement 
does  not  depend  significantly  upon  short  range  terrain  or  weather  factors. 

(3)  Gravel  Roads  (RG) .  Gravel  or  small  crushed  stone,  coarse  sand, 
or  similar  road  surface  substance  is  used  in  building  a  firm  surface  but 
requires  frequent  or  periodic  maintenance. 

(4)  Dirt  Roads  (RD) .  This  route  does  not  have  a  hard  surface  but  is 
of  dirt.  The  road  is  narrow,  following  undulations  of  the  terrain,  and  is 
marginally  maintained. 

c.  Unit  Formation: 

(1)  Column  March  (M) .  The  unit  is  in  a  column  march  formation  on  a 
road  or  cross  country. 


(2)  Reconnaissance  (R) .  The  unit  has  been  deployed  usually  on  a 
cross  country  movement  on  a  ground  reconnaissance  mission. 

(3)  Deployed  (D).  Unit  is  partially  deployed  in  a  formation  in 
anticipation  of  imminent  contact  with  the  enemy. 

d.  Allowable  Combinations  for  Mode  of  Travel.  Selected  combinations  of 
move  type,  route  type,  and  formations  are  allowable  in  the  submodel.  A  typi¬ 
cal  group  required  for  a  game  is  listed  in  subparagraph  2b. 

e.  Card  Type  and  Designator  (Columns  1-2).  The  card  format  for  this  type 
data  is  illustrated  in  Figure  IV-13-A-5.  In  column  1  is  preprinted  the  number 
1.  Make  no  changes.  In  column  2  only  one  of  two  designators  is  to  be  entered, 
"R"  for  Red  force  or  "B"  for  Blue  force.  Any  other  entry  will  he  unacceptable. 

f.  Travel  Mnemonic  (Columns  4-7).  In  these  columns  are  to  be  entered  one 
of  the  codes  suggested  in  subparagraph  b  above.  Each  individual  entering  data 
for  a  particular  force  may  use  such  mnemonics  as  desired  but  must  adhere  to  the 
rules  for  developing  abbreviations. 

g.  Index  to  Travel  Mnemonic  (Columns  8-9).  In  these  columns  are  entered 
the  number  of  the  mnemonic,  which  is  an  arbitrarily  assigned  number  ranging 
from  1  to  20.  It  is  not  essential  that  all  20  mnemonics  be  identified  at  the 
start  of  the  game  or  during  the  period  of  the  game. 

h.  Unit  Type  Designator  Mobility  Code  (Column  14).  A  code  is  established 
in  which  various  types  of  units  may  be  grouped  for  similar  movements.  Thus, 
as  shown  in  Figure  IV-13-A-2,  the  codes  I  and  T  are  used  to  indicate  infantrv 
category  of  movement  and  armor  vehicle  movement  respectively.  Other  possible 
listings  are  artillery,  engineer,  signal,  cavalry,  air  defense  units,  and 
others.  The  entries  I  and  T  are  essential  and  should  be  among  the  first  two 
entries  each  time  that  the  data  base  is  initiated. 

i.  Category  Description  (Columns  15-30).  These  data  are  not  entered  into 
the  data  base  but  are  of  assistance  in  checking  card  image  type  data  to  iden¬ 
tify  data  entered  into  the  files.  Write  an  abbreviation  for  the  description 
of  the  unit  mobility  category  code  inscribed  in  column  14.  This  may  be 
infantry  for  foot  and  armor  for  tank. 

j.  Index  to  Mobility  Category  Code  (Columns  31-50).  Refer  to  Figure 
IV-13-A-5.  Entries  for  columns  31-50  were  explained  in  subparagraphs  a  through 
d  above. 

4.  UTD  BY  MOBILITY  CATEGORY.  Data  for  this  card  format  are  prepared  concurrent 
with  that  for  the  ID  1401  card.  Both  deal  with  the  mobility  categories  and 
the  units  that  are  to  be  grouped  together  on  the  basis  of  having  similar  move¬ 
ment  characteristics.  The  format  of  the  UTDs  listed  by  mobility  category 
is  shown  in  Figure  IV-13-A-6. 
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Figure  1V-13-A-5.  Travel  Mode  and  Mobility  Category 
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a.  Card  Type  and  Force  Designator  (Columns  1-2)  .  The  card  type  is 
preprinted  with  the  number  1  as  shown  in  Figure  IV-13-A-6,  and  is  not  changed. 

In  card  column  2  is  to  be  entered  only  an  "R"  for  Red  forces  or  "8"  for  Rlue 
forces . 

b.  Mobility  Category  Code  (Column  4).  This  is  an  alphabetic  entry  of 
which  any  of  the  26  letters  of  the  alphabet  may  be  used.  The  letter  '0"  may 
be  ruled  out  in  that  it  resembles  zero,  as  is  also  the  case  with  the  letter 
”Z  ’  and  tiie  number  2.  Enter  the  letter  to  be  applied  to  one  of  the  mobility 
categories.  The  letter  "I"  must  be  reserved  for  foot  or  infantry  and  the 
letter  "T"  must  be  reserved  for  tanks  or  armor. 

c.  UTD  of  Units  in  this  Category  (Columns  9-12).  A  series  of  units  having 
similar  movement  characteristics  is  listed  in  these  card  columns.  Four  letters 
are  required  for  the  UTD,  and  the  movement  characteristics  are  dependent  upon 
the  primary  mission  assignments  anticipated  for  that  unit  plus  the  types  of 
vehicular  equipment  that  are  given  this  unit.  A  careful  examination  should 

be  made  to  assist  in  grouping  all  like  units  together:  however,  if  some  of 
the  units  are  overlooked,  or  their  grouping  cannot  be  readily  determined,  they 
may  be  entered  separately.  The  more  individual  entries  of  this  type  that  are 
made,  the  larger  the  data  burden  that  is  placed  on  the  user.  The  data  base 
for  constant  data  input  will  accept  each  unit  separately  or  in  combination 
with  others. 

d.  Other  UTDs  (Columns  14-67).  There  are  12  LTDs  that  may  be  entered  on 
this  card  format.  If  additional  space  is  required  to  enter  more  UTDs.  addi¬ 
tional  cards  may  be  used  for  this  purpose. 

e.  Additional  Cards.  Additional  cards  may  be  necessarv  to  enter  all  data 
needed  for  this  category  of  information.  These  cards  are  completed  as  explained 
above . 

5.  MOBILITY  CLASSIFICATION.  The  mobility  classification  is  the  grouping  of 
equipment  item  code  which  have  similar  movement  characteristics.  Each  class 
is  assigned  a  code  number  to  identify  the  classifications.  The  card  format 
used  in  transcribing  these  data  is  illustrated  in  Figure  IV-13-A-7. 

a.  Card  Type  and  Force  Indicator  (Columns  1-2).  The  preprinted  number  1 

is  in  card  column  1  and  is  not  to  be  changed.  In  card  column  2  is  entered  only 

an  "R"  for  Red  force  or  "B"  for  Blue  force. 

b.  Mobility  Class  Code  (Columns  5-6).  This  is  an  arbitrarily  selected 

number  assigned  to  a  grouping  of  like  vehicular  equipment  identified  by  their 
equipment  item  codes.  This  classification  number  may  range  from  1  through  20, 

but  only  12  to  15  such  classifications  may  be  needed. 

c.  Item  Code  (Columns  7-9).  The  equipment  item  code  is  entered  in  these 
card  columns.  The  equipment  items  are  vehicular  equipment  having  the  same 
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movement  characteristics  over  both  roads  and  cross  country  so  that  rates  will 
be  very  closely  allied,  and  overall  performance  will  be  very  similar. 

d.  Additional  Vehicles  (Columns  10-69).  As  additional  vehicular  ecuipment 
items  are  grouped  with  this  class,  they  are  entered  in  the  additional  columns 
provided  for  this  purpose.  Up  to  11  different  item  codes  can  be  entered  on 
this  card.  Additional  cards  are  prepared  for  groupings  beyond  11  in  any  one 
class . 

e.  Additional  Cards.  All  additional  cards  must  be  oreoared  as  exolained 
previously . 

6.  UTD  CLASS  EXCLUSION  LIST.  This  list  identifies  mobility  classifications 
that  are  nonrestrict ive  in  the  movement  of  the  unit:  i.e.,  vehicles  that  are 
not  considered  as  moving  with  the  parent  unit  and  will  not  hold  down  the  over¬ 
all  rate  of  movement.  Thus,  the  list  excludes  certain  mobility  classes  from 
the  move.  For  example,  it  might  be  desirable  to  allow  the  supply  vehicles 
organic  to  a  tank  unit  to  fall  behind  the  main  part  of  the  unit  and  not  re¬ 
strict  its  movement  rate  when  certain  travel  mode  mnemonics  are  being  used. 

The  exclusion  list  allows  this  to  be  accomplished.  The  format  of  this  with 
card  ID  1402  is  illustrated  in  Figure  IV-13-A-8,  Mobility  Exclusion  List. 

a.  Card  Type  and  Force  Designator  (Columns  1-2).  In  card  column  1  has 
been  preprinted  the  number  1,  make  no  change.  In  card  column  2  only  one  of 
two  entries  is  permitted,  "R''  for  Red  force  or  3"  for  Blue  force. 

b.  Unit  Type  Designator  (Columns  4-7).  For  each  UTD  listed  in  Card  ID 
0901  there  may  be  a  card  prepared  with  the  UTD  listed  in  these  columns. 

c.  Travel  Mode  Mnemonic  (Columns  9-12).  The  travel  mode  mnemonic  is 
taken  from  the  list  prepared  in  card  ID  1401. 

d.  Nonrestrict ive  Mobility  Classification  (0, lumns  13-15).  Enter  one  of 
the  mobility  classifications  that  were  develooed  in  card  ID  0902  which  will 

not  restrict  the  movement  of  this  unit. 

e.  Additional  Mobility  Classifications  (Columns  16-69).  If  there  are 
additional  mobility  classifications  that  will  not  restrict  the  movement  of 
this  unit  they  are  entered  in  these  card  columns.  Additional  cards  may  be 
prepared  with  more  mobility  classifications  if  needed. 

f.  Additional  Cards  (Columns  73-76).  Additional  cards  are  prepared  as 
described  above. 

7.  UNIT  ROAD  MOVEMENT  RATE.  The  rate  in  kilometers  per  hour  at  which  a  unit 
moves  over  the  roadways  is  entered  in  this  card  format.  The  controlling  fac¬ 
tors  are  the  mobility  category  code,  the  formation  code,  and  the  weather  and 
light  conditions.  For  each  such  combination  there  is  one  card  entry.  Refer¬ 
ring  to  Figure  IV-13-A-2,  Matrix  of  Movement  Mode  and  Mobility  Category,  each 
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number  1  entered  in  the  illustration  must  be  accounted  for  by  a  set  of  rates 
related  to  each  travel  mode.  For  example,  referring  to  Figure  IV-13-A-2, 
if  there  were  six  number  ones  (1)  entered  for  cavalry,  there  would  be  six  road 
movement  cards  prepared  for  each  of  the  formations.  The  formation  is  specifi¬ 
cally  the  last  letter  of  the  travel  mode.  Thus,  the  letter  M  is  a  march  column 
formation  for  ARAM.  The  letter  R  is  reconnaissance  formation  in  the  mode  labeled 
TR^R,  A  proportionate  number  of  cards  must  be  prepared  for  artillery.  In  this 
matter  a  check  list  can  be  developed  to  ensure  that  the  complete  constant  data 
for  this  portion  of  the  Movement  Model  is  ready  for  operations.  The  format 
of  this  card  is  illustrated  in  Figure  IV-13-A-9,  Unit  Road  Movement  Rates. 

a.  Card  Type  and  Force  Designator  (Columns  1-2).  In  card  column  1  has 
been  preprinted  the  number  1;  make  no  change.  In  column  2  enter  either  an  "R" 
for  Red  force  or  "B"  for  Blue  force. 

b.  Mobility  Category  Code  (Column  4).  From  Figure  IV-13-A-2,  select  the 
mobility  category  code  that  is  applicable  and  enter  it  in  column  4. 

c.  Formation  Code  (Column  5).  The  unit  formation  code  is  entered  in  this 
column.  Referring  to  Figure  IV-13-A-2  at  the  top  of  the  ligure  are  the  list¬ 
ings  of  the  travel  modes.  The  last  letter  on  the  travel  modes  is  an  indication 
of  the  formation.  The  three  formations  were  M  for  march  column,  R  for  recon¬ 
naissance,  and  D  for  deployed.  See  subparagraphs  3a(7)  through  3a(9)  for 

more  information. 


d.  Weather  and  Climatic  Conditions  (Columns  8-10).  In  subparagraphs  2b 
and  2c  are  listed  the  weather  and  day  or  night  conditions  and  their  abbrevi¬ 
ations.  These  conditions  are  entered  in  columns  8-10.  In  column  3  enter  D  for 
day  condition  or  N  for  night  condition.  In  column  9  always  enter  the  letter 
W.  In  column  10  the  index  of  the  weather  conditions  is  entered  as  1,  2,  or 
3  depending  upon  the  weather  type  being  considered.  There  are  six  possible 
combinations  of  light  and  weather  conditions.  They  are: 

.  DW1  -  Day,  weather  conditions  type  1 
.  DW2  -  Day,  weather  conditions  type  2 


DW3  -  Day,  weather  conditions  type  3 
NW1  -  Might,  weather  conditions  type  1 
MW2  -  Night,  weather  conditions  type  2 
NW3  -  Night,  weather  conditions  type  3. 


e.  Administrative  Move  on  Paved  Roads  Over  Good  Terrain  (Columns  16-20). 
Enter  the  rate  in  kilometers  per  hour  at  which  the  unit  will  move  over  this 
type  of  road. 
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f.  Other  Road  Conditions  Rates,  Kilometers  per  Hour  (Columns  1C--65). 

Rates  entered  in  these  card  columns  are  for  the  conditions  for  road  movement 
in  both  administrative  and  tactical  conditions.  This  information  is  entered 
after  being  acquired  from  authorized  sources.  Each  of  these  rates  is  differ¬ 
ent  and  should  be  stated  in  numerical  figures.  All  fractions  and  decimals 
are  reduced  to  whole  numbers,  and  only  whole  number  entries  are  acceptable. 

g.  Additional  Cards.  There  will  be  six  cards  for  each  mobility  category 
and  unit  formation.  Each  will  have  administrative  and  tactical  movement  rates 
on  paved,  gravel,  and  dirt  roads  for  a  specific  weather  and  day  or  night  con¬ 
dition  and  must  be  filled  out  completely  as  described  above. 

h.  Combinations  of  Tactical  and  Administrative  Moves.  Certain  combinations 
of  travel  modes  may  exclude  the  completion  of  selected  card  columns  on  this 
form.  For  example,  if  this  category  and  formation  combination  only  applies  to 
tactical  movement,  then  no  information  on  rates  will  need  to  be  entered  in  the 
administrative  move  columns.  Conversely,  if  the  move  is  administrative  only, 
then  the  tactical  columns  will  not  be  completed.  There  are  no  administrative 
moves  over  dirt  roads  since  there  is  no  column  provided  for  RD  indicating  dirt 
roads . 

8.  VEHICULAR  ROAD  MOVEMENT  RATES,  The  vehicular  road  movement  rates  provide 
the  speed  at  which  individual  vehicles  such  as  tanks  or  trucks  can  travel  over 
roadways  or  cross  country.  The  mobility  class  on  the  vehicular  road  movement 
rate  card  ID  1403  is  taken  irom  the  mobility  classification  card  0902;  that  is, 
the  classification  code  was  initiated  on  card  format  0902.  The  equipment 
item  code  was  also  listed  on  this  card  format  and  this  body  of  information  must 

be  related  to  that  of  movements  on  roads.  This  card  format  is  illustrated  in 

Figure  IV-13-A-10,  Vehicular  Road  Movement  Rate,  card  ID  1403.  Comparing  this 
format  with  that  in  Figure  IV-13-A-9  shows  that  the  card  format  segment  labeled 
unit  road  movement  tactical  move  is  identical  with  that  of  the  Figure  IV-13-A-10 
format. 

a.  Card  Format.  In  the  format  illustrated  in  Figure  IV-13-A-10,  the 

mobility  class  is  the  major  variable,  and  weather  and  light  conditions  with 
types  of  road  and  terrain  conditions  are  secondary.  The  same  weather  conditions 

exist  in  this  card  format  as  were  stated  in  road  movement  for  units.  The 

road  types  are  limited  to  paved,  gravel,  and  dirt  roads  as  were  for  tactical 
conditions  in  the  unit  move.  Thus,  the  weather,  light,  and  road  conditions 
considered  in  data  for  vehicular  road  movement  are  identical  in  nature  to  those 
required  for  unit  road  movement. 

b.  Card  Type  and  Force  Designator  (Columns  1-2).  Card  type  1  has  been 
preprinted  in  column  1  of  this  format  and  is  not  to  be  changed.  In  column  2 
only  one  of  two  authorized  characters  is  entered,  "R"  for  Red  force  or  "B" 
for  Blue  force. 

c.  Mobility  Class  (Columns  4-5).  The  mobility  class  must  agree  with  that 
assigned  in  card  ID  0902.  Care  must  be  exercised  to  ensure  that  each  mobility 
classification  listed  on  that  card  has  been  recorded  on  this  card  format  and  that 
appropriate  road  movement  rates  have  been  entered. 
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d.  Weather  Climatic  Conditions  (Columns  8-10).  In  subparagraphs  2b  and 

2c  were  listed  the  weather  and  day  or  night  conditions  and  their  abbreviations. 
These  weather  and  day  or  night  conditions  abbreviations  are  entered  exactly 
as  was  described  in  subparagraph  7d.  The  road  movement  rates  in  kilometers 
per  hour  will  be  developed  accordingly  with  the  stated  climatic  conditions. 

e.  Rate  with  Paved  Roads,  Good  Terrain  (Columns  16-20).  Enter  the  rate 
in  kilometers  per  hour  at  which  the  vehicle  will  move  over  these  roads  at 
these  weather  conditions. 

f.  Rate  with  Paved  Roads,  Poor  Terrain  (Columns  21-25).  Enter  the  rate 
in  kilometers  per  hour  at  which  vehicles  will  move  over  these  roads  at  the 
weather  conditions  specified. 

g.  Rate  with  Other  Road  and  Terrain  Types  (Columns  26-45).  Enter  in 
these  card  columns  the  rate  in  kilometers  per  hour  at  which  the  vehicles 
listed  in  this  mobility  class  will  travel  over  the  roads  as  stated  in  the 
terrain  and  under  the  weather  conditions  stipulated.  This  should  be  done  for 
gravel  as  well  as  dirt  roads. 

h.  Additional  Mobility  Classes.  The  card  format  as  shown  in  Figure 
IV-13-A-10  will  handle  one  mobility  class  under  one  type  of  weather  conditions. 
Additional  cards  are  prepared  for  other  mobility  classes  and  different  weather 
and  light  conditions. 

(1)  Additional  Weather  Conditions.  The  first  card  may  be  designated 
to  handle  daylight  with  no  rain  (DW1)  weather  conditions,  while  the  second 
set  of  weather  conditions  on  the  second  card  format  may  be  daylight  with  light 
rain  (DVTC).  Each  succeeding  card  format  with  a  different  combination  will 
require  data  entries. 

(2)  Mobility  Class  Rate  Tables  Required.  One  mobility  class  requires 
six  cards.  If  there  are  as  many  as  10  mobility  classes,  taken  from  card  ID 
0902,  then  60  cards  will  be  prepared. 

9.  UNIT  CROSS  COUNTRY  MOVEMENT  RATE.  Preparation  of  data  for  entries  in 
cross  country  movement  should  not  be  undertaken  until  the  travel  mode  and 
mobility  categories  are  completed  and  UTDs  have  been  grouped  by  mobility 
categories.  Referring  to  Figure  T.V-13-A-3,  card  ID  1401  and  card  ID  0901  should 
be  completed  prior  to  undertaking  the  unit  cross  country  movement  rates. 

a.  Card  Format.  The  format  for  this  card  type  is  illustrated  in  Figure 
IV-13-A-11,  Unit  Cross  Country  Movement  Rate  with  card  ID  1902.  The  variables 
required  on  this  card  are  mobility  category  code,  type  of  military  formation, 
weather  conditions,  and  20  movement  rates  corresponding  to  variations  in  ter¬ 
rain,  soil,  slope,  and  trafficability.  As  oart  of  the  check  on  this  card 
format,  for  each  number  1  entered  in  columns  31-50  of  card  format  ID  1401,  a 
cross  country  unit  movement  rate  for  the  combination  must  be  prepared.  It  is 
well  to  review  the  number  of  different  cards  to  prepare  for  unit  cross  country 
movement  and  to  ensure  that  the  data  entered  in  this  card  format  are  in  re¬ 
sponse  to  that  entered  in  card  ID  1401. 
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b.  Card  Type  and  Force  Designator  (Columns  1-2).  Preprinted  in  column  1, 
as  shown  in  Figure  IV-13-A-11,  is  the  number  1.  Make  no  change.  In  column  2 
enter  either  "R"  for  Red  force  or  "B"  for  Blue  force;  no  other  entry  is  acceptable. 

c.  Mobility  Category  (Column  4).  Enter  the  mobility  category  code  as 
assigned  in  card  ID  1401. 

d.  Military  Unit  Formation  Code  (Column  5).  The  unit  formation  code  is 
entered  here.  Referring  to  Figure  IV-13-A-2,  at  the  top  of  the  figure  are 
listings  of  the  travel  modes,  ihe  last  letter  on  the  travel  modes  is  an 
indication  of  the  formation.  The  three  formations  are  M  for  march  column,  R 
for  reconnaissance,  and  D  for  deployed.  See  subparagraph  3c  for  further 
details. 


e.  Weather  and  Climatic  Conditions  (Columns  7-9).  In  subparagraphs  2b 
and  2c  were  listed  the  weather  and  light  conditions  and  their  abbreviations. 
These  weather  conditions  abbreviations  are  entered  exactly  as  described  in 
subparagraphs  7d  and  8d. 

f.  Rate  with  Terrain  Flat  to  Gently  Rolling,  Forested,  Coarse-Grained 
(Columns  10-12).  Entered  here  is  the  rate  in  kilometers  per  hour  for  move¬ 
ment  over  this  type  of  terrain  and  in  accordance  with  the  weather  conditions 
stated  in  columns  7-9.  Only  whole  numbers  are  entered  in  these  card  columns. 
Decimals  or  fractions  are  rounded  to  the  nearest  whole  number,  and  the  figure 
entered  in  this  field  is  right  justified. 

g.  Rate  with  Terrain  Flat  to  Gently  Rolling,  Open,  Coarse-Grained 
(Columns  13-15) .  Enter  the  kilometers  per  hour  speed  that  this  mobility 
category  will  have  for  this  type  of  terrain,  weather  conditions,  and  other 
factors  concerned  with  the  units  grouped  together  to  form  the  category. 

h.  Rate  with  Other  Varying  Terrain  and  Soil  Conditions  (Columns  16-69). 
Entries  in  these  card  columns  are  in  kilometers  per  hour,  adjusted  to  meet  the 
cross  country  factors  that  the  units  will  encounter  and  considering  the  type 
of  vehicles  that  are  issued  that  unit  under  the  climatic  conditions  stated  in 
card  columns  7-9.  An  entry  should  be  made  for  each  terrain  type  until  data 
have  been  completed  for  all  20  types  of  terrain. 

i.  Additional  Categories.  One  card  format  can  record  the  data  for  one 
weather  condition  of  one  mobility  category.  Since  there  are  six  weather  or 
climatic  conditions  expressed,  for  each  mobility  category  there  will  be  six 
cards.  If  there  is  more  than  one  mobility  category,  12  or  more  cards  will  be 
us  ed . 


j.  Additional  Cards.  Additional  cards  will  be  required  as  more  categories 
are  defined.  Each  of  these  card  formats  will  have  the  number  1  in  card  column 
1  and  the  ID  1403  in  card  columns  73-76. 

10.  VEHICULAR  CROSS  COUNTRY  MOVEMENT  RATES.  Vehicular  cross  country  movement 
will  have  similar  factors  to  those  which  relate  to  unit  cross  country  movement. 
Desired  for  data  entry  into  this  card  format  are  values  for  mobility  classifi¬ 
cation,  weather  or  climatic  conditions,  and  movement  rates  corresponding  to 
20  degrees  of  terrain,  slope,  and  soil  traf ficability . 

t 

a.  Card  Contents.  The  data  elements  in  this  card  format  are  very  similar 
to  those  for  the  unit  cross  country  movement  rate.  Figure  IV-13-A-12,  Vehicular 
Cross  Country  Movement  Rate,  illustrates  the  card  format  with  card  ID  1404. 
Instructions  for  entry  of  data  are  almost  identical  and  will  be  explained  only 
briefly. 

b.  Card  Type  and  Designator  (Columns  1-2).  The  card  column  1  has  been 

preprinted  with  the  number  1,  and  no  change  is  to  be  made.  Card  column  2  will 

have  only  one  of  two  entries,  "R"  for  Red  force  and  "B"  for  Blue  force. 

c.  Mobility  Classification  (Column  4).  Reference  is  made  to  the  format 
for  card  ID  0902  in  which  the  various  mobility  classifications  were  listed. 

For  each  of  the  classes  listed  in  card  ID  0901  a  set  of  cards  will  be  prepared 

of  the  type  in  ID  1404.  This  may  be  used  as  a  check  list  to  ensure  that  all 

the  required  cross  country  movement  rates  for  vehicles  are  entered  in  the  data 
base. 

d.  Weather  Climatic  Conditions  (Columns  7-9).  In  subparagraphs  2b  and 
2c  were  listed  the  weather  and  light  conditions  and  their  abbreviations. 

These  conditions  are  entered  exactly  as  described  before  in  subparagraphs 
7d,  8d,  and  9d. 

e.  Rate  for  Terrain  Flat  to  Gently  Rolling,  Forested,  Coarse-Grained 

f  (Columns  10-12) .  Enter  here  the  kilometers  per  hour  rate  for  this  type  of 
^  terrain  and,  in  accordance  with  the  weather  conditions  expressed  in  card 
columns  7-9,  the  speed  which  this  class  of  mobility  is  anticipated  to  have. 

This  will  be  a  weighted  figure  which  represents  the  collective  speeds  of  the 
various  types  of  vehicles  grouped  in  this  classification. 

f.  Rate  for  Terrain  Flat  to  Gently  Rolling,  Open,  Coarse-Grained  (Columns 

‘  13-15).  Enter  here  the  kilometers  per  hour  speed  that  this  mobility  category 

will  have  for  this  type  of  terrain,  weather  conditions,  and  other  factors 
associated  in  the  combination  of  vehicles  into  this  classification. 

»  g.  Rate  for  Other  Terrain,  Forestation,  and  Soil  (Columns  16-69).  The 

cross  country  movement  rates  in  kilometers  per  hour  for  the  remaining  types 
of  terrain  are  entered. 
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Figure  IV-13-A-12.  Vehicular  Cross  Country  Movement  Rate 


h.  Additional  Classes.  In  one  card  format  can  be  recorded  the  movement 
rates  for  one  mobility  class  and  one  weather  condition.  Since  there  are  a 
maximum  of  six  weather  and  light  conditions  there  may  be  as  many  as  six  dif¬ 
ferent  cards  prepared  for  one  mobility  classification.  If  there  are  two  or 
more  mobility  classifications  then  there  will  be  12  or  more  cards  prepared. 

i.  Additional  Cards.  The  additional  cards  must  all  bear  the  same  card 
type  number  1  as  printed  in  column  1  and  must  have  the  ID  1404  in  card  columns 
73-76. 

11.  GROUND  MOVEMENT  FUEL  CONSUMPTION  RATE.  Each  of  the  vehicles  listed  in 
card  ID  0902,  Mobility  Class,  must  have  its  fuel  consumption  listed  in  this 
card  format.  Some  of  the  vehicles  or  equipment  items  are  stationary,  such  as 
air  compressors  for  pneumatic  hammers,  and  for  these  type  of  vehicles  or  equip¬ 
ment  items  the  unit  of  measure  for  fuel  is  gallons  per  hour. 

a.  Format.  The  card  format  with  identifier  1501  includes  data  for  both 
moving  and  stationary  equipment  items.  Since  each  item  of  equipment  is  specif¬ 
ically  identified  with  its  equipment  item  code  all  items  that  consume  fuel 
must  be  included  in  this  card  format,  illustrated  in  Figure  IV-13-A-13.  The 
equipment  item  list  used  in  TOE  load  (see  Chapter  3  of  this  section)  may  be 
consulted  to  ensure  that  a  complete  check  list  of  fuel-consuming  items  have 
been  included  in  this  segment  of  the  data  base. 

b.  Card  Type  and  Designator  (Columns  1-2).  In  column  1  has  been  entered 
the  number  1.  In  column  2  "B"  for  Blue  force  or  "R"  for  Red  force  is  entered. 

c.  Equipment  Item  Code  (Columns  3-6).  The  number  assigned  the  equipment 
item  as  its  code  is  to  be  entered  in  these  columns.  This  code  positively 
identifies  this  item  and  sets  it  apart  from  all  others. 

d.  Gallons  of  Fuel  per  Kilometer,  Cross  Country  (Columns  11-16).  Enter 
the  gallons  of  fuel  per  kilometer  that  this  type  equipment  will  achieve  in 
cross  country  operations.  The  types  of  cross  country  to  be  considered  are  all 
conditions  of  terrain  as  listed  in  both  cards  ID  1403  and  1404.  The  consump¬ 
tion  rate  will  be  a  composite  figure  for  both  day  and  night  travel  and  that 
conducted  during  the  spectrum  of  weather  conditions.  Consumption  rates  may  be 
expressed  in  decimal  fractions. 

e.  Gallons  of  Fuel  per  Kilometer,  Paved  Roads  (Columns  17-22).  The 
consumption  rate  of  fuel  in  gallons  per  kilometer  is  to  be  entered  for  this 
vehicle  when  on  paved  roads. 

f.  Gallons  of  Fuel  per  Kilometer,  Gravel  Roads  (Columns  23-28).  The 
consumption  rate  of  fuel  in  gallons  per  kilometer  is  entered  for  this  vehicle 
when  on  gravel  roads. 

g.  Gallons  of  Fuel  per  Kilometer,  Dirt  Roads  (Columns  29-34).  The 
consumption  of  fuel  at  the  gallons  per  kilometer  rate  is  to  be  entered  here 
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for  dirt  roads  under  all  types  of  weather  conditions  and  considering  night  or 
day  driving.  If  the  vehicle  or  equipment  item  operates  while  stationary,  such 
as  an  electric  generator,  then  these  card  columns  are  left  blank. 

h.  Engineer  and  Stay  Type  Activities  (Columns  35-58).  Several  selected 
equipment  types,  such  as  tanks  of  an  armored  unit,  armored  personnel  carriers, 
or  self-propelled  artillery,  are  not  entered  in  these  columns  because  they  are 
not  used  in  engineering  type  activities  during  the  course  of  the  game. 

i.  Engineer  Activity,  Temperature  Between  32°  and  90°  (Columns  35-40). 
Enter  the  gallons  per  hour  of  fuel  consumed  by  engineer  type  equipment  for 
temperature  ranges  between  32°  and  90°  in  these  columns. 

j.  Engineer  Activity,  Temperature  Higher  Than  90°  or  Lower  Than  32° 
(Columns  41-46) .  Enter  the  gallons  per  hour  of  fuel  consumed  by  engineer  type 
equipment  for  temperature  ranges  higher  than  90°  and  lower  than  32°  in  these 
columns . 


k.  Stay  Activity,  Temperature  Between  32°  and  90°  (Columns  47-52).  Enter 
the  consumption  of  fuel  in  gallons  per  hour  for  activity  that  takes  place  in 
an  assembly  area  or  for  stationary  equipment. 

l.  Stay  Activity,  Temperature  Higher  Than  90°  or  Lower  Than  32°  (Columns 
53-58) .  In  these  card  columns  enter  the  consumption  of  fuel  which  has  ambient 
temperatures  of  higher  than  90°  or  lower  than  32° . 

m.  Equipment  Items.  One  card  is  prepared  for  each  equipment  item  code 
identified.  As  a  check  use  the  list  of  vehicles  developed  with  the  mobility 
classification  and  the  data  sheets  prepared  for  the  TOE  load  (see  Chapter  3) 
for  equipment  items  which  consume  fuel  but  do  not  carry  a  load  or  are  used 
in  combat  and  require  a  resupply  of  fuel,  such  as  tanks. 

12.  AIRCRAFT  FUEL  CONSUMPTION  RATES.  Part  of  the  criteria  of  whether  a 
mission  can  be  assigned  aircraft  is  a  requirement  that  a  specific  amount  of 
fuel  be  aboard.  If  that  quantity  of  fuel  is  not  already  aboard  the  aircraft 
or  available  at  the  airbase,  then  the  mission  may  be  denied.  Thus,  the  fuel, 
consumption  rate  by  aircraft  and  the  draw  on  local  stocks  is  important  in 
determining  whether  that  aircraft  can  take  off  for  mission  strikes.  The  trans¬ 
port  system  to  provide  that  fuel  and  similar  logistics  tasks  provide  more 
realism  for  simulation  in  the  DIVWAG  system. 

a.  Card  Format.  The  card  format  with  card  identifier  1405  is  illustrated 
in  Figure  IV-13-A-14,  that  portrays  the  actual  punch  card  layout  that  records 
data.  It  will  be  referred  to  frequently  in  describing  the  data  elements  and 
indicating  the  exact  card  columns  where  the  data  are  to  be  entered.  The  vari¬ 
ables  of  which  values  are  to  be  entered  in  these  card  columns  are  defined  as: 

(1)  The  equipment  item  code  in  which  a  specific  item  is  identified 
as  a  consumer  of  fuel. 
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(2)  Altitude  at  which  the  fuel  consumption  rate  changes. 

(3)  Cruise  speed  beyond  which  the  consumption  of  fuel  changes 
considerably. 

(4)  Fuel  consumption  rates  for  aircraft  in  various  combinations  of 
variable  definitions  (2)  and  (3)  above. 

(5)  Aircraft  fuel  consumption  while  parked  on  runways  at  varying 
temperatures. 

b.  Card  Type  and  Force  Designator  (Columns  1-2).  The  printed  figure  1 
in  the  first  column  is  not  to  be  changed.  In  column  2  may  be  entered  either 
"B"  for  Blue  force  or  "R"  for  Red  force. 

c.  Equipment  Item  Code  (Columns  4-6).  Enter  the  code  number  for  this 
specific  aircraft  as  identified  by  the  number. 

d.  Altitude  Cutoff,  Feet  (Columns  11-16).  Enter  the  altitude  in  feet 
which  causes  a  change  in  fuel  consumption. 

e.  Cruise  Speed,  Knots  per  Hour  (Columns  17-22).  Enter  the  cruise  speed 
in  knots  per  hour  of  the  aircraft  above  which  the  fuel  consumption  changes 
considerably. 

f.  Gallons  per  Hour,  Below  Critical  Cruise  Speed  and  Below  Critical 
Altitude  (Columns  23-28).  Enter  the  gallons  per  hour  fuel  consumption  below 
critical  altitude  and  cruise  speed. 

g.  Gallons  per  Hour,  Below  Cruise  Speed  but  Above  Critical  Altutude 
(Columns  29-34).  Enter  the  fuel  consumption  in  gallons  per  hour  when  the 
aircraft  is  traveling  below  cruise  speed  but  at  an  altitude  above  the  cutoff 
point. 


h.  Gallons  per  Hour,  Greater  Than  Cruise  Speed  but  Lower  Than  Altitude 
Cutoff  (Columns  35-40) .  Enter  the  gallons  per  hour  fuel  consumption  when  the 
aircraft  is  traveling  at  greater  than  cruise  speed  but  at  an  altitude  lower 
than  critical. 

i.  Gallons  per  Hour,  Cruise  Speed  and  Altitude  Greater  Than  Cutoff 
(Columns  41-46).  The  gallons  per  hour  consumption  of  fuel  by  this  aircraft 
is  to  be  entered  when  the  aircraft  is  above  altitude  and  speed  cutoff  limits. 

j.  Aircraft  Parked  at  Airbase  (Columns  47-58).  These  fuel  consumptions 
in  gallons  per  hour  are  used  when  the  aircraft  is  parked  on  the  runway.  The 
fuel  consumption  is  not  for  in-flight  or  propulsion  needed  such  as  when  on 
air  strikes.  The  consumption  varies  with  the  ambient  temperature,  and  the 
two  ranges  are  between  32°  and  90®  or  higher  than  90°  and  lower  than  32°. 


IV-13-A-39 


k.  Aircraft  Stay  Mode,  Temperature  Between  32°  and  90°  (Columns  47-52). 
Enter  the  fuel  consumption  rate  in  gallons  per  hour  for  aircraft  parked  on 
the  strip  at  an  airfield  with  the  engine  running  or  using  the  electric 
generator  or  other  devices. 

l.  Aircraft  Stay  Mode,  Temperature  Higher  than  90°  or  Lower  Than  32° 
(Columns  53-58).  Enter  the  fuel  consumed  when  the  aircraft  is  parked  on 
the  runway  with  engine  idling  at  temperatures  of  greater  than  90°  or  less 
than  32°. 

13.  BREACH  OR  FORCE  DECISION  TABLES.  A  breach/force  decision  table  is 
required  for  each  movement  priority  used  in  the  game.  If  the  procedure 
discussed  in  subparagraph  2c(7)  was  followed,  the  necessary  data  can  be  copied 
directly  from  the  work  forms  to  the  data  format. 

a.  The  Card.  The  breach/force  decision  table  data  card  is  identified  by 
the  characters  0903  in  columns  73-76  as  illustrated  in  Figure  IV-13-A-15.  Only 
one  card  is  required  for  each  table. 

b.  Card  Type  and  Designator  (Columns  1-2).  The  number  1  is  preprinted 
in  column  1.  Column  2  must  contain  a  "B"  if  the  table  applies  to  the  Blue 
force  and  an  "R"  if  the  table  is  to  be  used  by  the  Red  force. 

c.  Movement  Priority  (Column  4) .  The  movement  priority  (a  numeric  value 
1-n,  where  n  is  the  number  of  tables)  with  which  this  table  will  be  associated 
in  entered  in  column  4. 

d.  Vehicles  Lost  (Columns  7-8).  The  maximum  number  of  casualties  which 
the  first  row  of  this  decision  table  will  apply  to  is  entered  in  these  columns. 
The  value  wbi.h  would  be  entered  here  for  the  example  shown  In  Figure  IV-13-A-4 
is  "1". 

e.  Breach/Force  Code  (Column  10).  If  the  unit  should  force  the  barrier 
when  the  number  of  vehicles  input  in  columns  7-8  or  fewer  will  be  lost  and  up 

to  0.5  hour  may  be  required  to  breach  the  barrier,  a  2  is  placed  in  this  column. 
Otherwise,  a  number  1  is  entered  in  column  10. 

f.  Other  Vehicles  Lost  and  Breach/Force  Codes  (Columns  12-66).  Data 
entered  in  these  fields  complete  the  table  and  are  similar  to  those  described 
for  columns  7-8  or  10.  No  vehicles  lost  value  is  entered  for  the  last  row  of 
the  table  (columns  56-66).  This  row  is  assumed  to  apply  to  all  losses  greater 
than  the  value  entered  in  columns  39-40. 

g.  Other  Cards.  Complete  one  card  for  each  movement  priority  used  in  the 
game. 

14.  MOVEMENT  MODEL  CONSTANT  DATA  DECK  STRUCTURE.  This  paragraph  describes 
the  data  deck  structure  for  constant  data  input  used  in  the  Movement  Model. 

The  cards  making  up  the  deck  and  the  order  in  which  they  must  be  read  into 
the  DIVWAG  system  are  discussed. 
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a.  Movement  Model  Constant  Data  Input  Cards.  The  cards  for  the  Movement 
Model  constant  data  input  are  listed  in  Figure  IV-13-A-16.  The  figure  shows 
card  type,  title,  and  identification.  The  far  right  column  shows  the  program 
used  to  load  the  data. 


Card 

Type 

Card  Title 

Card 

ID 

Load 

Program  Name 

1 

Travel  Mode  Mobility  Category 

1401 

M0VELD 

1 

Mobility  Category  Table 

0901 

MO VELD 

1 

Mobility  Class  Table 

0902 

MOVELD 

1 

Mobility  Class  Exclusion 

1402 

MOVELD 

1 

Mobility  Category  Road  Movement  Rate 

1901 

MOVELD 

1 

Mobility  Category  Cross  Country  Movement 

1902 

MOVELD 

1 

Mobility  Class  Road  Movement  Rate 

1403 

MOVELD 

1 

Mobility  Class  Cross  Country  Movement 

1404 

MOVELD 

1 

Ground  Fuel  Consumption  Rate 

1501 

MOVELD 

1 

Air  Fuel  Consumption  Rate 

14r>5 

MOVELD 

1 

Breach/Force  Decision  Table 

0903 

MOVELD 

Figure  IV-13-A-16.  Movement  Model  Constant  Data  Input  Cards 


b.  Creating  Constant  Data  Files  for  Movement.  The  Movement  Model  constant 
data  input  file  is  created  by  reading  in  the  data  deck  structured  as  illustrated 
in  Figure  IV-13-A-17.  At  the  right  are  shown  the  subdecks  that  form  the  Move¬ 
ment  Model  data  deck,  with  Blue  force  data  preceding  Red  force  data.  At  the 
left  side  of  the  figure  are  11  groupings  of  card  formats,  which  are  used  to 
assemble  the  subdecks  shown  at  the  right. 

(1)  Card  Groupings,  Figure  IV-13-A-17  shows  in  position  one  the 
mobility  category  travel  mode,  card  type  1,  ID  1401  grouping.  Immediately 
behind  this  grouping  is  the  first  card  of  the  mobility  category,  card  type  1, 

ID  0901  grouping.  All  the  Blue  force  cards  are  arranged  first  and  assembled 
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as  part  of  the  Blue  force  subdeck.  The  Red  force  cards  are  assembled  into 
their  ovm  subdeck,  and  the  two  are  then  submitted  for  reading  by  the  computer 
system.  A  card  with  the  characters  END  DATA  punched  in  columns  73  through  80 
must  follow  the  Red  force  subdeck. 

(2)  Subdeck  Structure.  After  the  groupings  of  cards  are  aligned  as 
shown  on  the  left  of  Figure  IV-13-A-17,  all  the  blue  force  cards  are  then 
assembled  for  the  first  subdeck.  The  Red  force  movement  data  are  then  organized 
in  the  11  groupings  as  shown  at  Che  left  of  the  figure.  The  data  deck  is  then 
ready  for  insertion  of  the  system  control  cards  and  submission  to  the  computer 
system  for  creation  of  the  Movement  Model  constant  data  input  files. 

c.  Updating  Movement  Model  Constant  Data  Files.  Changes  to  the  data  read 
into  the  constant  data  files  for  the  Movement  Model  can  be  readily  accomplished 
through  the  use  of  the  retained  Movement  Model  data  deck.  The  updating  may 
consist  of  correction  of  an  error  in  one  data  element,  the  deletion  of  infor¬ 
mation,  or  the  addition  of  new  data. 

(1)  Correcting  an  Error.  The  card  with  the  error  or  data  to  be 
changed  is  located  and  a  new  card  produced  with  the  correct  or  changed  data 
punched  in.  The  old  card  is  removed  from  the  deck,  and  the  new  card  is  in¬ 
serted  in  its  location.  The  entire  data  deck  for  both  Red  and  Blue  forces  is 
then  submitted  for  another  run  on  the  computer  system.  The  recreation  of  the 
constant  data  files  through  reading  in  the  data  deck  with  the  changed  data  on 
cards  constitutes  the  correction  of  an  error  or  the  changing  of  a  data  element. 

(2)  Deletion  of  Information.  The  deletion  process  may  consist  of 
eliminating  the  entire  file  or  deleting  one  data  element  or  a  record.  To 
delete  a  data  element,  select  the  card  or  caTds  having  the  unwanted  data.  These 
cards  are  removed  from  the  data  deck,  and  the  purged  deck  is  then  submitted 

for  reread  to  the  computer  system.  The  omission  of  cards  will  cause  that  data 
to  be  eliminated  from  the  data  base  in  the  process  of  recreating  the  constant 
data  files  for  the  Movement  Model. 

(3)  Addition  of  Data.  Data  may  be  added  at  any  time  prior  to  the 
start  of  the  game.  The  procedure  is  to  prepare  the  cards  that  are  to  have  the 
data  and  integrate  them  into  the  data  deck  by  placing  each  of  the  card  formats 
in  the  appropriate  subdeck  as  illustrated  in  Figure  IV-13-A-17.  When  these 
cards  have  been  accurately  integrated  into  the  data  deck  the  completed  and 
expanded  data  deck  is  then  submitted  to  the  computer  system  for  reread.  Each 
time  data  are  entered  in  the  Movement  Model  constant  data  input  file  printouts 
are  generated  showing  the  new  file  information. 
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APPENDIX  B 


MOVEMENT  MODEL  PROGRAM  DESCRIPTIONS 


1.  INTRODUCTION.  The  routines  MOVESR,  MOVEDT,  OBSRCH,  and  MOVE  are  the 
component  routines  of  the  Movement  Model.  The  first  three  routines  perform 
all  calculations  necessary  to  time  sequence  the  movement  events  in  the  DIVWAG 
system.  The  routine  MOVE  is  executed  at  the  appropriate  time  to  update  the 
parameters  modified  by  the  movement  event.  The  routine  0VER13  serves  as  an 
interface  between  routines  MINUET,  MOVE,  and  SUPRES.  The  macro  flow  of  the 
Movement  Model  is  shown  in  Figures  IV-13-1,  IV-13-3,  IV-13-4,  and  IV-13-6. 

2.  ROUTINE  MOVESR: 


a.  Purpose.  This  routine  determines  the  endpoint  coordinate  of  the  model 
move  segment.  This  coordinate  may  be  set  to  the  order  segment  endpoint,  the 
point  of  segment  intersection  with  a  terrain  cell  boundary,  or  the  point  at 
which  a  segment  intersects  a  barrier  line  or  facility,  whichever  is  closer  to 
the  unit's  current  location.  If  the  unit  is  flying,  the  model  move  segment 
will  always  be  identical  to  the  order  segment.  The  routine  may  also  initiate 
a  battle  as  units  of  opposing  forces  approach  each  other. 

b.  Input  Variables: 

(1)  Standard  Common  Block  Areas.  UMAIN,  UCOOP ,  BPOINT,  BMPRTY , 
and  RMPRTY. 

(2)  Other  Variables: 


Name 

Source 

Contents 

KOF 

DF2 

Barrier  information. 

IBSRCH  ONE  Parameters  used  to  communicate  with  OBSRCH. 


IDEC 

DF9 

MVRATE 

ONE 

IBAR  ONE 


Force/breach  decision  table. 

Unit  movement  rate.  It  is  set  to  zero  at  the 
beginning  of  each  order  segment  and  is  used 
by  MOVESR  to  determine  if  an  order  segment 
must  be  processed. 

Code  of  barrier  which  unit  anticipates 
crossing.  IBAR  is  set  to  zero  if  no  known 
barrier  is  in  the  unit's  path,  is  set  equal  to 
the  barrier  code  if  the  unit  is  expecting  to 
contact  a  barrier  at  the  end  of  this  model 
move  segment,  and  is  set  to  the  negative  of 
the  barrier  code  is  the  unit  is  crossing  a 
barrier. 
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Name 

Source 

Contents 

IBCHIN 

ONE 

Chaining  parameter  used  to  force  units  crossing 
a  barrier  at  the  same  facility  to  do  so  in 
order  of  priority.  IBCHIN  is  set  to  zero  if 
the  unit  is  not  in  a  barrier  chain,  to  minus 
one  if  the  unit  is  last  in  the  chain,  or  to  the 
IUID  of  the  next  unit  in  the  chain. 

FORCTM 

ONE 

Time  required  to  force  an  active  barrier  if  the 
value  is  positive.  If  the  value  is  negative, 
it  is  the  negative  of  the  barrier  code  of  the 
barrier  the  unit  expects  to  cross  while 
traveling  along  this  order  segment. 

FRCEOH 

ONE 

Item  code  of  the  vehicle  used  to  force  the 
barrier  if  the  value  is  positive.  If  it  is 
negative,  it  contains  the  negative  of  the 
barrier  code  of  the  barrier  the  unit  expects 
to  avoid  by  being  routed  to  one  of  its 
endpoints . 

CBJX, 

CBJY 

ONE 

Coordinate  of  segment  intersection  with  barrier 
line,  or  facility  or  end  point  unit  is  being 
routed  to.  If  there  are  no  barriers,  it  will 
be  set  to  the  coordinate  of  the  order  segment 
objective. 

ATBARX, 

ATBARY 

ONE 

Coordinate  of  facility,  barrier  endpoint,  or 
point  of  segment  intersection  with  barrier 
line. 

FORCCU 

ONE 

The  casualties  that  will  be  assessed  a  unit 
choosing  to  force  an  active  barrier. 

EOHI 

DF16 

Equipment  type  codes. 

c.  Output  Variables: 

(1)  Standard  Common  Block  Variables.  MEVTX,  MEVTY,  NORD,  and  DELT. 

(2)  Other  Variables: 


Name 

Destination 

Contents 

KOF 

DF2 

Barrier  information. 

IENGRQ 

DF12 

Request  for 

support  sent  to  the  Engineer  Model. 

IBSRCH 

ONE 

Parameters 

used  to  communicate  with  OBSRCH. 

IBAR 

ONE 

As  defined 

for  input  variables. 
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Nac.^ 

Destination 

Contents 

IBCHIN 

ONE 

As 

defined 

for 

input 

variables 

FORCTM 

ONE 

As 

defined 

for 

input 

variables 

FRCEOH 

ONE 

As 

defined 

for 

input 

variables 

CBJX, 

CBJY 

ONE 

As 

defined 

for 

input 

variables 

ATBARX 

ONE 

As 

defined 

for 

input 

variables 

ATBARY 

ONE 

As 

defined 

for 

input 

variables 

FORCCU 

ONE 

As 

defined 

for 

input 

variables 

d.  Logical  Flow  (Figure  IV-13-B-1) : 

(1)  Block  1.  If  Che  unit  is  out  of  fuel,  it  will  be  halted  and  will 
remain  on  a  STAY  event  until  it  is  resupplied. 

(2)  Block  2.  If  the  unit  is  flying,  barriers  and  terrain  have  no 
effect  upon  its  movement,  so  the  model  move  segment  is  set  to  the  order 
segment  and  control  passes  to  block  6. 

(3)  Block  3.  At  this  point,  IBAR  is  interrogated  to  determine  if 
Che  unit  is  at  a  barrier.  If  IBAR  equals  zero,  the  unit  is  not  at  a  barrier. 
If  IBAR  is  positive,  the  unit  is  at  a  barrier  and  ready  to  cross.  If  IBAR 

is  negative,  the  unit  has  crossed  the  barrier  and  is  ready  to  continue  its 
movement . 

(4)  Block  L5000.  If  the  unit  has  crossed  the  barrier,  it  is  removed 
from  the  crossing  order  queue  (chain)  established  for  that  barrier;  the 
following  unit,  if  any  exists,  is  placed  first  in  the  queue.  The  remainder 

,  of  the  original  unit's  order  segment  is  again  searched  for  barriers  as  it 

continues  its  movement,  and  an  event  initiating  the  next  unit's  crossing  is 
set  up. 

(5)  Block  L990.  If  MVRATE  equals  zero,  the  unit  is  beginning  its 
movement  along  an  order  segment,  and  control  passes  to  block  L1000;  other¬ 
wise,  control  goes  to  block  L2000. 

(6)  Block  L1000.  As  the  unit  begins  moving  along  each  order  segment, 
'  that  segment  is  searched  for  an  intersection  with  barriers  known  to  the  unit's 

force  intelligence.  This  allows  early  rerouting  of  the  unit  to  be  accom- 
i  plished  or  an  early  request  for  engineering  assistance  to  be  made  if  either 
action  is  appropriate.  The  end  of  segment  to  be  searched  parameters  (ENDPTX 
,  and  ENDPTY)  are  set  equal  to  the  order  segment  objective  point  (OBJX  and 

OBJY) ,  the  flag  used  to  indicate  only  force  intelligence  information  is  to 
be  used  (INACT)  is  set  to  1,  and  the  search  routine  (OBSRCH)  is  called. 


t 
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MOVES* 


Figure  IV-13-B-1. 


Routine  MOVESR  (continued  next  page) 


IV-13-B-4 


13-B-l.  Routine  MOVESR  (concluJ.d) 
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(7)  Block.  L1100.  If  the  information  returned  by  OBSRCH  (IBSRCH) 
indicates  a  barrier  line  intersects  the  move  segment,  a  decision  is  made  in 
block  4  to  determine  the  unit's  appropriate  action;  otherwise,  control  passes 
to  block  L1900. 

(8)  Block  4.  If  the  facility  a\ ailability  code  (NBARF)  is  greater 
than  zero  an  existing  facility  is  available,  NBARF  is  equal  to  its  code,  and 
the  unit  will  be  routed  to  it  by  setting  its  coordinate  of  facility  parameters 
(ATBARX  and  ATBARY)  and  its  coordinate  of  segment  intersection  parameters 
(CBJX  and  CBJY)  to  the  coordinate  returned  by  OBSRCH  (FACX  and  FACY).  FORCTM 
will  be  set  to  negative  NBARF.  If  NBARF  is  less  than  zero,  the  values  returned 
in  FACX  and  FACY  are  the  coordinates  of  the  endpoint  of  the  barrier  the  unit 
may  be  routed  to.  This  routing  is  accomplished  by  setting  ATBARX,  ATBARY, 

CBJX,  and  CBJY  as  described  above  and  setting  FRCEOH  to  the  negative  of  NBARF. 
If  NBARF  equals  zero,  no  facility  or  endpoint  is  available  and  control  goes 

to  block  L1115.  If  passage  is  possible,  control  passes  to  block  L1900. 

(9)  Block  L1115.  If  the  barrier  intersected  is  active,  the  unit  may 
choose  to  force  it  rather  than  suffer  a  delay  waiting  for  it  to  be  breached. 
IDEC  is  a  decision  cable  which  is  a  function  of  the  unit's  movement  priority, 
the  number  of  casualties  that  will  be  assessed  the  unit  if  it  forces  the 
barrier,  and  the  length  of  time  chat  will  be  required  to  breach  it.  IDEC  is 
interrogated  to  determine  which  course  of  action  the  unit  is  to  pursue:  force, 
go  to  block  L1900,  not  force,  go  to  block  L1500. 

(10)  Block  1 1500.  If  the  unit  cannot  bypass  the  barrier  or  make  use 
of  an  existing  facility,  it  will  request  the  Engineer  Model  to  construct  a 
facility  at  the  point  of  intersection  by  setting  parameters  in  the  array  IENGRQ 
and  calling  EVTSET. 

(11)  Block  L1900.  If  the  barrier  search  just  completed  was  an  order 
segment  search,  the  movement  path  must  be  searched  for  barriers  again  using 
actual  information.  This  is  accomplished  by  passing  to  block  L2Q00;  otherwise, 
control  goes  to  block  5. 

(12)  Block  L2000.  The  model  move  segment  endpoint  coordinates 
(MEVTX  and  MEVTY)  are  set  to  CBJX  and  CBJY.  If  CBJX  and  CBJY  are  not  in  the 
same  terrain  cell  as  the  unit,  MEVTX  and  MEVTY  are  reset  to  the  coordinates 
of  the  point  of  intersection  of  the  model  move  segment  and  the  terrain  cell 
boundary.  This  new  segment  is  then  searched  for  barriers  by  setting  INACT 
equal  to  minus  one,  ENDPTX  and  ENDPTY  to  MEVTX  and  MEVTY,  and  calling  OBSRCH. 
Giving  INACT  the  value  of  minus  one  indicates  to  OBSRCH  that  actual  barrier 
information  is  to  be  used,  and  the  flow  starting  at  block  L11QQ  is  rejoined. 

(13)  Block  L3000.  When  the  unit  arrives  at  a  barrier  it  is  placed 

in  the  barrier's  crossing  order  queue.  The  units  are  ordered  by  move  priority 
(MVPRTY)  and,  within  priority,  on  a  first-in-first-out  basis. 

(14)  Block  L4000.  If  another  unit  is  crossing  the  barrier  at  this 
point  or  the  engineers  are  in  the  process  of  constructing  the  facility  when 
the  unit  arrives,  the  facility  is  not  available  and  the  unit  must  wait.  If 
neither  of  the  above  is  so  and  the  unit  decided  to  force  the  barrier,  it 
constructs  its  own  facility  and  is  assessed  casualties  caused  by  forcing  the 
barrier. 
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(15)  Block  L4300.  The  time  required  to  cross  the  facility  is 
calculated  by  multiplying  the  crossing  rate  by  the  number  of  vehicles  in  the 
unit  and  is  assessed  to  the  unit  by  giving  it  a  STAY  order  for  that  length  of 
time. 


(16)  Block  L3400.  If  the  facility  is  not  available,  the  unit  is 
given  an  order  to  STAY  until  the  end  of  the  period.  This  order  will  be 
interrupted  and  the  unit  will  continue  its  movement  if  the  facility  becomes 
available  before  the  end  of  the  period. 

(17)  Block  5.  Routine  MOVESR  also  initiates  a  battle  when  a  unit 
listed  in  a  battle  scenario  and  executing  an  ADVANCE  order  moves  within  3000 
meters  of  an  appropriate  enemy  unit.  At  this  time  the  unit’s  ADVANCE  order  is 
terminated,  and  control  is  passed  from  the  Movement  Model  to  the  Ground  Combat 
Model.  As  the  battle  is  initiated,  the  ADVANCE,  WITHDRAW,  or  PREPARE  orders 
of  all  units  listed  in  its  battle  scenario  are  terminated,  and  control  of 
those  units  is  assumed  by  the  Ground  Combat  Model.  Units  listed  in  the  battle 
scenario  that  begin  execution  of  an  ADVANCE,  WITHDRAW,  or  PREPARE  order  after 
the  battle  has  begun  have  those  orders  terminated  and  their  control  is 
assumed  by  the  Ground  Combat  Model  at  that  time. 

(18)  Block  6.  The  MOVEDT  routine  determines  the  unit's  rate  of 
movement  and  calculates  the  time  required  by  the  unit  to  traverse  the  model 
segment  described  by  MOVESR. 

3 .  ROUTINE  MOVEDT : 

a.  Purpose.  This  routine  determines  the  unit's  rate  of  movement  and 
calculates  the  time  required  to  travel  along  the  model  move  segment. 

b.  Input  Variables: 

(1)  Standard  Common  Block  Areas.  UMAIN,  TERAIN,  WEATHR ,  TCLOCK, 
LGTPER,  HOUR,  MINUTE,  BMNT,  BMCMRT ,  EENT ,  RMCMRT ,  RFTMRT,  BFTMRT,  and  IBFOOD. 

(2)  Other  Variables: 


Name 

Source 

Contents 

IVDU 

DF9 

Mobility  class  indices. 

MAXRAT 

DF14 

Mobility  class  maximum  move  rates. 

IDS 

DF14 

Mobility  class  exclusion  table. 

MRTN 

DF19 

Unit  movement  rate. 

ITLOST 

ONE 

Time  lost  during  move. 

•••• 
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Output  Variables: 


c . 

(1)  Standard  Common  Block  Variables.  MV RATE,  DELT,  XKK,  YKK,  and  IOUT. 

(2)  Other  Variables: 

Name  Destination  Contents 

ITLOST  ONE  Time  lost  during  move. 

d.  Logical  Flow  (Figure  IV-13-B-2) : 

(1)  Block  1.  Calculate  the  unit's  distance  moved  in  the  X  and  Y 
directions  (XKK  and  YKK)  by  subtracting  the  unit's  current  location  parameters 
(XACT  and  YACT)  from  the  unit's  model  move  segment  parameters  (MEVTX  and 
MEVTY) .  The  length  of  the  model  move  segment  (DIST)  is  equal  to  the  square 
root  of  XKK  squared  plus  YKK  squared. 

(2)  Block  2.  If  the  unit  is  flying,  the  movement  rate  (MVRATE)  is 
calculated  by  converting  the  airspeed  given  in  the  order  from  knots  to  meters 
per  minute. 

(3)  Block  3.  A  unit's  ground  movement  rate  depends  upon  type  of  move, 
type  of  route,  unit's  formation,  light  level,  weather,  and  terrain.  The  unit's 
route  type  index  (RRRCD,  characters  2  and  3)  may  be  RA,  RG,  RD,  or  CC;  and  the 
route  type  code  (IROUT)  is  assigned  a  value  of  1,  2,  3,  or  4  respectively. 

The  allowed  formation  types  are  M,  R,  or  D  (RRRCD,  character  4)  with  the 
formation  type  code  (IFORM)  being  assigned  a  value  of  1,  2,  or  3  respectively. 
The  day-night  code  (IDORN)  is  set  to  0  if  the  time  is  between  BMNT  and  EENT ; 
it  is  set  to  3  otherwise.  The  precipitation  index  (PRECIP)  has  a  value  of  0, 

1,  or  2  for  none,  light,  or  heavy  precipitation  respectively,  and  the  fog 
index  (FOGIDX)  is  set  to  0  for  no  fog  or  to  1  for  presence  of  fog.  The 
precipitation  code  (IPRECP)  is  set  equal  to  the  precipitation  index  unless  fog 
is  present;  in  that  case  it  is  set  equal  to  2.  If  the  route  type  is  CC,  the 
movement  rate  table  index  (IRATE)  is  calculated  using  the  traf f icability  index 
contained  in  characters  3  and  4  of  RFSC  by  the  equation: 

IRATE  -  10  *  RFSC(3)  +  RFSC(4) 

+  (IDORN  +  PRECP)  *  20  (IV-12-B-1) 

If  the  unit  is  moving  on  a  road,  the  roughness-vegetation  code  (ITER)  must  be 
calculated.  It  is  set  to  2  if  the  roughness-vegetation  index  [RFSC(l)]  is 
greater  than  5  and  set  to  1  otherwise.  The  move  type  code  must  also  be  set. 

It  is  equal  to  4  if  the  move  type  index  (RRRCD,  character  1)  is  equal  to  T; 
it  is  0  otherwise.  The  road  movement  rate  table  index  is  then  calculated  by 
the  equation: 


IRATE  -  (IDORN  +  IPRECP)  *  10  +  I AT 

+  (IROUT  -  1)  *  2  +  ITER  (IV-12-B-2) 
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(4)  Block  4.  A  unit's  movement  rate  may  not  be  greater  than  the  rate 
of  its  slowest  vehicle  that  has  not  been  excluded.  The  list  of  vehicular  rates 
(MAXRAT)  is  obtained  from  data  file  14  using  the  movement  rate  table  index 
calculated  in  block  3.  The  exclusion  table  (IDS),  also  from  data  file  14,  is 
used  to  determine  which,  if  any,  of  the  vehicular  rates  will  not  be  allowed  to 
restrict  the  unit's  movement.  The  slowest  vehicle  movement  rate  (MRT)  is  set 
to  the  slowest  nonexcluded  value  in  the  vehicular  rate  list  applying  to  a 
vehicle  in  the  unit. 

(5)  Block  5.  The  movement  rate  table  index  is  used  to  obtain  the 
unit's  movement  rate  (MRTN)  from  the  cables  on  data  file  19.  If  the  table 
requested  has  not  been  loaded,  the  table  containing  tank  data  is  used.  If 
the  travel  mode  mnemonic  supplied  cannot  be  used  with  the  unit's  mobility 
category,  data  from  the  dismounted  infantry  table  are  used.  If  the  movement 
rate  of  the  slowest  vehicle  (MRT)  is  less  than  the  unit  movement  rate  (MRTN) , 
the  movement  rate  (MVRATE)  is  set  equal  to  MRT;  otherwise,  it  is  set  to  MRTN. 

(6)  Block  6.  The  time  required  by  the  unit  to  travel  the  length  of 
the  model  move  segment  (DELT)  is  calculated  by  dividing  the  length  of  the 
model  move  segment  by  the  movement  rate. 

(7)  Block  7.  The  record  of  the  movement  event  is  written  on  the 
period  history  tapes  at  this  point. 

(8)  Block  8.  The  routine  CCOLLM,  which  determines  whether  the  unit 
will  be  detected  by  an  opposing  force  sensor  while  it  is  moving,  is  called 
before  returning.  Routine  CCOLLM  is  described  in  the  Intelligence  and  Control 
Model . 

4.  ROUTINE  OBSRCH; 

a.  Purpose.  This  routine  determines  if  a  move  segment  will  intersect  a 
barrier  line.  If  an  intersection  is  found,  an  attempt  will  be  made  to  locate 
an  existing  facility  or  the  endpoint  of  a  barrier  line  that  the  unit  may  be 
routed  to.  The  resulting  information  is  returned  to  MOVESR. 

b.  Input  Variables: 

(1)  Standard  Common  Block  Areas.  UMAIN. 

(2)  Other  Variables: 


Name 

Source 

Contents 

IBIG1 

DF16 

Quadrature  description. 

1 

OBFACC 

ONE 

Unit/barrier  status  flag:  »  0,  unit  is  not 
aware  of  any  barrier;  >  0,  unit  is  at  this 
barrier  and  needs  information  about  it; 

<  0,  unit  has  crossed  this  barrier,  and 
do  not  pick  it  up  this  search. 
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Name 


Source 


Contents 


IBIG  DF22  List  of  barrier  code  numbers  and  their 

locations . 

IOF  DF2  Data  describing  the  barrier. 

c.  Output  Variables: 

Name  Destination  Contents 

IDUM(120)  TWO  Barrier  information  requested  by  MOVESR. 

d.  Logical  Flow  (Figure  IV-13-B-3) : 

(1)  Block  1.  Scratch  common  is  stored  on  data  file  36,  the  basic 
quadrature  information  necessary  is  retrieved  from  data  file  16  and  stored  in 
IBIG1,  and  other  variables  used  by  the  routine  are  given  initial  values.  The 
move  segment  OBSRCH  which  is  being  requested  to  search  is  broken  into  search 
segments  at  this  point. 

(2)  Block  L21.  If  the  parameter  OBFACC  has  a  value  greater  than  zero, 
it  is  assumed  to  be  a  barrier  code,  and  information  concerning  that  barrier 
will  be  returned.  In  this  case,  control  passes  to  block  L191. 

(3)  Block  2.  The  routine  CRTQD  is  called  to  generate  the  quadrature 
code  associated  with  this  particular  search  segment.  The  quadrature  code  is 
an  eight -character  code  describing  the  location  of  a  line  segment.  Routine 
CRTQD  is  described  in  the  Engineer  Model. 

(A)  Block  L65.  The  quadratures  are  screened  to  determine  which  ones 
may  contain  barrier  segments  intersecting  this  search  segment.  Of  the  17 
quadratures,  6  to  13  are  eliminated  by  this  screen. 

(5)  Block  L60.  The  17  records  of  data  file  22  correspond  to  the  17 
quadratures.  Each  record  contains  the  barrier  codes  and  quadrature  codes  of 
the  barriers  associated  with  the  corresponding  quadrature.  The  appropriate 
record  is  retrieved  from  data  file  22  at  this  point. 

(6)  Block  L61.  If  this  quadrature  contains  no  barriers  and  another 
quadrature  remains  to  be  searched,  control  is  transferred  to  block  L70. 

(7)  Block  L70.  If  other  quadratures  are  to  be  searched,  parameters 
aiding  in  the  barrier  line  and  search  segment  intersection  checks  are  set,  and 
control  is  transferred  to  block  L60. 

(8)  Block  L72.  If  OBFACC  is  negative,  it  is  the  negative  of  the 
barrier  code  of  the  barrier  segment  the  moving  unit  has  just  crossed.  This 
barrier  segment  will  not  be  considered  to  intersect  the  move  segment. 

(9)  Block  L500.  The  quadrature  code  of  the  barrier  is  compared  to 
the  quadrature  code  of  the  search  segment  to  determine  if  they  intersect. 
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YES 


(10)  Block  L401.  If  the  actual  intelligence  information  flag  (INACT) 
is  equal  to  one,  indicating  that  only  force  intelligence  information  is  to  be 
used,  barriers  not  known  to  the  unit's  force  will  not  be  detected.  If  INACT 
is  less  than  one,  information  on  all  barriers  will  be  used. 

(11)  Block  L123.  Barriers  which  have  been  removed  are  assumed  to 
cause  no  delay  to  moving  units  and  are  ignored. 

(12)  Block  L120.  The  utility  routine  INTSPT  is  used  to  determine  if 
the  barrier  line  and  search  segment  intersect.  If  they  do,  the  coordinates  of 
the  point  of  intersection  are  returned. 

(13)  Block  L130.  If  this  barrier  is  nearest  the  unit's  current 
location  (i.e.,  would  be  encountered  first  by  the  moving  unit),  its  barrier 
code  and  coordinates  are  stored. 

(14)  Block  L300.  If  other  barriers  are  associated  with  this 
quadrature,  they  are  processed. 

(15)  Block  3.  If  the  segment  being  checked  for  intersection  with 
barriers  is  described  by  the  unit's  current  location  and  a  potential  facility 
and  no  barriers  are  discovered,  the  facility  is  accepted  and  control  is 
transferred  to  block  L923.  If  a  barrier  does  exist  between  the  unit  and  this 
facility,  OBSRCH  will  proceed  to  search  for  another  facility. 

(16)  Block  4.  If  no  barrier  lines  are  intersected  by  the  search 
segment,  control  is  transferred  to  block  L100. 

(17)  Block  L191.  If  the  move  segment  being  searched  intersects  a 
barrier  segment,  OBSRCH  attempts  to  locate  an  existing  facility  or  the  endpoint 
of  a  barrier  line  within  reasonable  distance  of  the  intersection  point  of  the 
move  segment  and  barrier  line.  Reasonable  distance  is  defined  as  one-half 

the  sum  of  the  unit's  width  and  depth.  If  a  facility  (or  endpoint)  is  found, 
the  new  segment  described  by  the  unit's  current  location  and  the  facility  is 
searched  to  determine  if  it  intersects  with  other  barriers. 

(18)  Block  1.923.  At  this  point  all  remaining  parameters  requested  by 
MOVESR  are  set.  If  the  barrier  is  active  (e.g.,  a  minefield),  an  estimate  of 
the  time  required  to  breach  it,  type  vehicle  that  might  be  used  to  force  it, 
and  number  of  casualties  that  would  be  assessed  a  unit  forcing  it  are  required. 
A  crossing  rate  in  terms  of  vehicles  per  centiminute  is  required  for  all 
facilities.  The  barrier  code,  coordinates  of  the  intersection  point,  and  the 
facility  indicator  were  set  elsewhere  in  this  routine. 

(19)  Block  L100.  If  the  last  search  segment  has  been  searched  and 
no  barriers  have  been  detected,  parameters  indicating  this  are  set  and 
control  returns  to  the  calling  routine. 

5.  ROUTINE  MOVE: 

a.  Purpose.  The  routine  updates  t’'.e  unit's  coordinates,  calculates  the 
amount  of  food  and  fuel  consumed  en  route,  and  subtracts  these  amounts  from  the 
unit’s  supplies  on  hand. 
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b. 


Input  Variables: 


(1) 

Standard  Common 

Block  Areas. 

UMAIN,  NXTC ,  and  NYTC 

(2) 

Other  Variables: 

* 

Name 

Source 

Contents 

C3 

DF15 

Class 

III 

consumption  rates. 

RTEMV 

DF14 

Class 

IIIA  consumption  rates. 

K.EOH 

DF9 

Equipment 

item  codes  of  aircraft 

fuel  consumption  rates  have  been  defined. 


c.  Output  Variables: 

(1)  Standard  Common  Block  Variables.  XACT,  YACT,  XACTL,  YACTL, 

EOH,  and  ACTVTY . 

(2)  Other  Variables: 

Name  Destination  Contents 

UNTLOC  TWO  Unit  location  table. 

d.  Logical  Flow  (Figure  IV-13-B-4) : 

(1)  Block  1.  Set  unit's  last  location  parameters  (XACTL  and  YACTL) 

to  unit's  current  location  parameters  (XACT  and  YACT).  Update  current  location 
parameters  to  the  model  move  segment  parameters  (MEVTX  and  MEVTY) . 

(2)  Block  2.  The  route  type  may  be  cross  country  (CC) ,  asphalt 
surface  road  (RA) ,  gravel  road  (RG) ,  or  dirt  road  (RD) .  The  route  type  code 
(IROUT)  is  given  a  value  of  1,  2,  3,  or  4  respectively  if  the  unit  is  moving 
on  the  ground,  or  a  value  of  5  if  the  unit  is  flying. 

(3)  Block  3.  If  the  unit's  updated  current  location  is  outside  the 
defined  battle  area,  the  unit's  current  location  parameters  are  set  to  the 
unit's  last  location  parameters. 

(4)  Block  4.  Consumption  of  Class  I  supplies  is  modeled  by 
multiplying  the  unit's  personnel  strength  (PRESTR  +  SUPSTR)  by  the  force 

r  Class  I  consumption  rate  (IBFOOD  for  Blue,  IRFOOD  for  Red)  and  subtracting 
this  value  from  the  amount  of  Class  I  on  hand,  E0H(1) . 


(5)  Block  L2010.  If  the  unit  is  moving  on  the  ground,  Ciass  III 
a  supplies  are  consumed.  The  consumption  rate  is  a  function  of  route  type; 
therefore,  the  route  type  code  is  used  in  selecting  the  correct  consumption 
rate  table  from  data  file  15.  The  sum  of  the  consumption  rates  for  various 
types  of  vehicles  multiplied  by  the  number  of  vehicles  of  that  type  in  the 
unit  is  subtracted  from  the  amount  of  Class  III  on  hand,  E0H(2) . 

t 
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yit* ... 


-  v 


KOVt 


Figure  IV-13-B-4.  Routine  MOVE 
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(6)  Block  L2060.  If  the  unit  is  flying,  it  consumes  Class  IIIA 
supplies.  This  consumption  rate  is  dependent  upon  aircraft  type,  flight 
speed,  and  altitude.  The  amount  consumed  is  computed  by  summing  the  products 
of  consumption  rates  of  aircraft  types  and  the  numbers  of  aircraft  of  each 
type  in  the  unit.  This  value  is  then  subtracted  from  the  amount  of  Class  IIIA 
on  hand,  E0H(3) . 

(7)  Block  6.  The  current  location  of  the  unit  is  stored  in  UNTLOC 
where  it  may  be  easily  accessed  by  other  routines  in  the  DIVWAG  system. 

(8)  Block  7.  Parameters  describing  the  masking  effect  of  the  terrain 
surrounding  the  unit's  current  location  (MASKF)  are  updated  by  the  routine 
UPMASK. 

6.  ROUTINE  0VER13.  This  routine  routes  a  call  to  routine  MOVE  if  ETTAB(l) 
in  Common  ONE  equals  2.  It  routes  a  call  to  routine  SUPRES  if  ETTAB(l) 
equals  8. 


i 

IV-13-B-17 


APPENDIX  C 


MOVEMENT  MODEL  OUTPUT  DESCRIPTIONS 


1.  INTRODUCTION.  This  appendix  contains  samples  and  detailed  descriptions 
of  printed  output  from  routines  within  the  Movement  Model  of  the  Period 
Processor.  A  figure  depicts  the  format  of  each  routine  printout.  In  the 
figures  an  alphabetical  descriptor  designates  an  appropriate  line  or  group  of 
lines  that  is  explained  in  the  following  paragraphs. 

2.  ROUTINE  MOVE.  The  printout  from  this  routine,  presented  in  Figure 
IV-13-C-1,  lists  those  variables  involved  in  the  consumption  of  fuel  and  the 
updating  of  the  unit's  location.  The  explanation  is  as  follows: 


Output 

Descriptor 

A 


B 


Explanation 

This  printout  lists  the  unit's  identification  and  identification 
record  number;  location  at  the  beginning  of  the  move  segment 
(X,YACT);  location  at  the  end  of  the  move  segment  (MEVTX.Y); 
NORD;  amounts  of  class  I,  class  III,  and  class  IIIA  supplies 
on  hand  at  the  beginning  of  the  move;  and  the  length  of  time, 
in  centiminutes ,  required  to  traverse  this  move  segment. 

This  list  is  identical  to  that  in  descriptor  A  with  the 
exception  that  the  travel  mode  mnemonic  rather  than  delta 
time  is  printed  as  the  last  item.  X.YACT  equals  MEVTX.Y 
showing  the  unit's  location,  has  been  updated;  the  amounts 
of  class  I  and  class  III  have  decreased  by  the  amount  con¬ 
sumed;  and  NORD  is  now  negative,  indicating  movement  to  a 
coordinate  input  in  the  DSL  order  has  been  accomplished. 


3.  ROUTINE  MOVEDT.  The  printout  from  this  routine  (shown  in  Figure 
IV-13-C-2)  lists  those  parameters  involved  in  the  selection  of  the  movement 
rate  and  calculation  of  the  time  required  to  complete  the  designated  move¬ 
ment  segment.  The  print  is  controlled  by  print  switch  3. 


Output 

Descriptor 


Explanation 


A  UID  *  Unit's  identification. 

*  IUID  =  Unit's  identification  record  number. 

UTD  •  Unit's  type  designator. 

*  MOVE  CODE  “  Travel  mode  mnemonic  input  in  the  DSL  order. 

TRAF.  INDEX  ■  Soil/slope/traf ficability  index  associated  with 

•  the  terrain  cell  the  unit  is  moving  in. 

FOG  •  Fog  index  at  this  time. 

RAIN  ■  Precipitation  index  at  this  game  time. 


f 
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Output 

Descriptor 


B 


C 


D 


Explanation 


MOB.  CATG.  =  Mobility  category  assigned  the  unit  in  the 
constant  data  input. 

EXCLU.  INDEX  =  Index  to  the  list  of  nobility  classes  not 
allowed  to  slow  unit  movement.  This  is  also  assigned 
in  constant  data  input. 

RATE  PT.  *  Pointer  to  the  record  containing  the  unit  movement 
rates  to  be  used  with  the  current  conditions. 

This  table  of  mobility  class  versus  equipment  on  hand  (EOH) 

allows  the  mobility  classes  effecting  the  unit  is  movement 
rate  to  be  determined.  The  mobility  classes  are  integer 
and  are  printed  with  an  12  format.  The  EOH  array  is 
floating  point  and  is  printed  with  an  II  format,  giving 
an  X  if  the  quantity  of  a  particular  item  is  not  zero. 

The  amount  of  the  item  is  not  important,  but  it's  presence 
is.  In  the  example  shown,  the  circled  items  indicate 
vehicles  that  belong  to  mobility  classes  2,  3,  5,  and  6 
are  present  in  the  unit,  and  their  rates  may  be  considered 
as  a  limiting  rate  of  unit  movement. 

The  vehicular  or  mobility  class  rates  are  listed  with  a  zero 
indicating  the  rate  is  to  be  considered  as  a  limiting 
movement  rate  of  the  unit  shown.  The  exception  to  this 
is  the  first  pair  (30)  that  contains  the  foot  movement 
rate  which  is  never  considered  to  be  a  restriction.  For 
example,  the  vehicular  limiting  rate  is  32  if  the  vehicles 
in  mobility  class  6  were  not  allowed  to  limit  the  movement 
rate  of  the  unit,  the  6M  pair  (32  0)  would  be  32  1,  and 
the  limiting  rate  would  be  36. 

UID  ■  Unit's  identification. 

IUID  =  Unit's  identification  record  r 

MOVE  RATE  ■  Movement  rate  selected  foi  -.r.'.t  from  the  tables 
(the  minimum  of  slowest  vehicular  rate  .d  the  unit  rate). 

UNIT  RATE  *  Unit  movement  rate  selected  from  the  tables. 

RATE  -  Floating  point  equivalent  of  unit  rate,  or  if  the 

movement  is  by  road,  it  is  equal  to  the  unit  rate  divided 
by  1.1. 

UPDATE  PT.  »  Pointer  to  the  record  that  the  unit  movement 
rate  was  selected  from. 

TIME  LOST  -  Amount  of  time  that  the  unit  has  lost  during  this 
move  as  the  result  of  barriers,  suppression,  or  having 
its  rate  restricted  by  a  vehicle. 

DIST  -  Number  of  meters  the  unit  is  to  move  this  segment. 
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4.  ROUTINE  MOVESR: 


a.  The  printout  from  this  routine  (shown  in  Figure  IV-13-C-3)  lists  those 
parameters  required  in  the  selection  of  the  next  model  move  segment,  the 
barrier  interface  parameters,  and  battle  entry  information. 

Output 

Descriptor  Explanation 

A  UID  =  Unit’s  identification. 

IUID  =  Unit's  record  number  identification. 

IBAR  »  Code  of  barrier  that  unit  anticipates  crossing. 

MOVRATE  *  Unit's  movement  rate. 

FORCTM  *  Time  required  to  force  an  active  barrier. 

FRCEOH  =  Item  code  of  the  vehicle  used  to  force  the  barrier. 
IBCHIN  »  Chaining  parameter  used  to  force  units  crossing  a 

barrier  at  the  same  facility  to  do  so  in  order  of  priority. 


B  NBARL  »  Code  of  the  barrier  encounter  which  does  not  contain 

a  facility. 

CPX,Y  «  Coordinates  of  the  point  at  which  the  barrier  may 
attempt  to  be  breached  or  forced. 

NBARF  =•  Code  of  the  barrier  encountered  which  contains  a 
facility  permitting  the  unit  to  cross. 

FACX,Y  *  Coordinates  of  the  facility. 

BRCHTM  *  Time  required  to  break  the  barrier. 

FORCTM  *  Time  required  to  force  the  barrier. 

CROSKT  =  The  number  of  vehicles  per  minute  which  may  cross 
the  facility. 

C  This  message  indicates  the  unit  involved  in  this  movement 

is  advancing  to  battle  MECH1. 

D  The  units  listed  in  this  statement  may  be  involved  in  the 

battle  listed  above. 

E  SEPARATION  ■  This  is  the  distance,  in  meters,  between  the 

units  initiating  the  battle. 

F  X.YACT  -  See  Chapter  2,  DIVWAG  Data  Files,  of  Section  VII. 

MEVTX.Y  -  See  Chapter  2,  DIVWAG  Data  Files,  of  Section  VII. 

CBJX.Y  ■  Coordinate  of  segment  intersection  with  barrier 
line,  or  facility  or  end  point  unit  is  being  routed  to. 

OBJX.Y  -  Chapter  2,  DIVWAG  Data  Files,  of  Section  VII. 

IBAR  -  Code  of  barrier  which  unit  anticipates  crossing. 

DELT  ■  The  time,  in  centiminutes ,  required  to  traverse  this 
model  move  segment  (described  by  X,YACT  and  MEVTX,Y). 
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Output 

Descriptor 

G 


H 


Explanation 

IBCHIN  =  See  descriptor  B. 

ICHAR  =  See  descriptor  B  in  Section  VII-2-A  (File  2). 

IBAR  *  Code  of  barrier  that  unit  anticipates  crossing. 

RQIUID  =  The  IUID  of  the  unit  requesting  activity  by  the 
Engineer  Model. 

BUID  ■  The  six-character  mnemonic  identifier  of  the  barrier. 

UID  =  Unit's  identification. 

IUID  =  Unit's  record  number  identification. 

IBAR  *  Cede  of  barrier  unit  anticipates  crossing. 

MAXD  =  The  maximum  dosage  accumulated  by  the  unit  to  date. 

MVRATE  *  Unit's  movement  rate. 

D  =  The  distance  the  unit  would  be  subjected  to  radiation. 

TDDS  «  The  total  of  the  nuclear  radiation  dosage  the  unit  has 
received  to  date  and  the  dosage  which  will  be  received  if 
the  unit  traverses  this  barrier. 

IRAD  *  This  is  the  pointer  to  the  smallest  radius  which  may 
be  used  to  access  the  unit. 

RADIUS  *  The  radius  of  the  nuclear  barrier. 


5.  ROUTINE  OBSRCH.  The  printout  from  this  routine  (presented  in  Figure 
IV-13-C-4)  shows  whether  a  move  segment  will  intersect  a  barrier  line.  If  so, 
a  facility  or  end  point  of  a  barrier  line  that  a  unit  may  be  routed  to  is 
found. 


Output 

Descriptor 


Explanation 


A  The  first  print  from  OBSRCH  gives  the  width  and  depth  of  the 

unit  whose  path  is  being  examined  for  barriers/facilities. 
The  5001  print  then  gives  the  eight-character  quadrature 
code  defining  the  location  of  the  line  segment  given  by 
XL0C4,  YL0C4  and  XL0C3,  YL0C3.  Each  print  will  trace 
part  of  the  larger  line  from  the  first  XL0C4,  YL0C4  given 
to  the  last  XL0C3,  YL0C3  listed  provided  no  3008  print 
is  encountered,  or  the  last  XL0C3,  YL0C3  listed,  if  a  3008 
print  occurs,  will  indicate  the  last  point  of  access  for 
the  unit  before  it  encounters  an  obstacle.  The  3008  print 
indicates  a  barrier  was  encountered  requiring  some  consol¬ 
idation  or  redirection  of  forces  to  bypass  it. 

B  If  no  3008  print  occurs  this  line  of  output  will  also  not  be 

present.  This  print  identifies  the  barrier  or  facility 
giving  the  record  numbers  of  the  adjacent  barriers/ 
facilities  which  form  part  of  the  same  barrier  line,  the 
coordinates  which  define  this  segment,  the  barrier  mnemonic, 
the  size  or  density  (for  minefields) ,  the  eight-character 
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Routine  OBSRCH  Print  Statements 


Output 


Descriptor 


C 


status  code  for  the  barrier ,  and  its  task  and  troop  type 
requirements  for  both  Red  and  Blue.  The  XINT  print  gives 
the  exact  location  of  intersection  of  the  barrier  and  line 
segment  of  movement  for  the  unit. 


The  3610  print  identifies  the  search  as  now  attempting  to  look 
for  facilities  in  following  segments  of  the  same  line.  The 
DIST  print  gives  the  distance  to  the  following  end  point 
of  the  barrier  and  the  maximum  search  radius  allowable 
for  bypassing  the  barrier.  The  FACX  =  print  identifies 
the  type  of  action  required  of  the  unit;  i.e.,  whether 
a  facility  is  available  for  crossing  or  whether  the  barrier 
must  be  breached  or  forced.  If  a  facility  is  available, 

its  coordinates  are  printed  as  FACX  *  _ and  FACY  = _ , 

with  the  record  number  of  the  facility  as  NBARF  * .  Should 
a  decision  to  breach  or  force  be  necessary,  the  coordinates 
of  intersection  are  printed  beside  CPX  *  and  CPY  *  with 
the  barrier  record  number  on  data  file  2  given  as 
NBARC  »  .  Whether  this  is  a  bridge  or  barrier  is 

then  identified  by  the  IBARTP  value. 


Additional  prints  from  OBSRCH  occur  as  SRCHRO  =  _  SRDIST  *  when  a 

preceding  segment  to  the  one  intersected  is  an  existing  bridge.  The  meanings 
of  the  two  values  are  just  reversed  from  the  DIST  print  mentioned  above. 

The  3641  print  identifies  the  facility  found  as  an  end  of  a  barrier  line  in 
the  direction  of  the  following  barrier  segments  to  the  one  intersected. 
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SOURCE  LISTINGS  FOR  PERIOD  PROCESSOR  MOVEMENT  MODEL 


(AVAILABLE  UNDER  SEPARATE  COVER) 
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CHAPTER  14 


ENGINEER  MODEL 


1.  MILITARY  ACTIVITY  REPRESENTED: 

a.  General.  The  Engineer  Model  represents  combat  engineer  activities 
in  support  of  a  division  in  combat. 

b.  Engineer  Missions.  The  generalized  missions  of  the  division  engineer 
battalion  are: 

.  To  increase  the  combat  effectiveness  of  the  division 
by  means  of  engineer  combat  support 

.  To  carry  out  an  infantry  combat  mission  when  required. 

The  Engineer  Model  addresses  only  the  first  mission. 

c.  Engineer  Functions.  Functions  performed  by  the  division  engineer 
battalion  to  carry  out  the  engineer  combat  support  mission  fall  into  two 
broad  categories,  termed  hard  support  functions  and  soft  support  functions. 

(1)  Hard  Support  Functions.  These  functions  have  the  objective  of 
facilitating  or  enhancing  friendly  force  mobility  and  impeding  or  degrading 
hostile  force  mobility;  they  include  such  activities  as  breaching  of  minefields 
and  bridging  of  gaps. 

(2)  Soft  Support  Functions.  These  functions  influence  combat  power 
only  indirectly;  they  include  such  activities  as  supply  of  potable  water, 
providing  technical  advice,  and  supplying  locally  available  construction 

nati rials. 

d.  Model  Constraints  and  Capabilities.  The  Engineer  Model  is  limited  to 
portrayal  of  those  hard  support  functions  related  to  the  mobility  element  of 
combat  power. 

(1)  The  model  is  capable  of  simulating  three  types  of  functions  or 
activities: 

(a)  Build.  The  build  function  is  defined  as  the  construction 
of  a  new  barrier  or  facility.  It  also  includes  maintenance  or  improvement 
of  an  existing  barrier  or  facility  and  repair  or  rebuilding  of  a  breached 
barrier  or  facility. 


1.  A  barrier  is  defined  as  any  feature,  natural  or  man-made,  which  tends 
to  reduce  the  mobility  of  military  forces.  A  facility  is  defined  as  any 
feature,  natural  or  man-made,  which  tends  to  reduce  the  effect  of  a  barrier 
(e.g.,  defiles  or  passes  in  ridge  line),  or  to  neutralize  or  negate  the 
barrier  (e.g.,  rc  is,  brid  >,  and  fords). 
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(b)  Breach.  The  breach  activity  is  defined  as  the  disruption 
of  the  functional  mission  of  a  barrier  or  facility.  To  breach  a  barrier  is 
to  clear  a  passageway  through  or  across  the  barrier.  To  breach  a  bridge  is 
to  disrupt  its  function  as  a  facility.  (A  bridge  is  a  facility  because  it 
provides  a  passageway  across  a  stream  or  gap  or  other  form  of  barrier.)  To 
breach  implies  functional  disruption  only  and  does  not  imply  total  elimina¬ 
tion;  the  latter  is  covered  by  the  remove  activity. 

(c)  Remove.  The  remove  function  is  defined  as  the  100  percent 
clearance  or  neutralization  of  a  barrier  or  facility.  Removal  as  played  by 
the  model  is  only  of  a  destructive  nature.  Destructive  removal  implies  total 
destruction  rendering  the  facility  useless  for  reconstruction  or  reuse. 

(2)  Engineer  tasks  in  the  model  are  limited  to  minefields,  fords, 
bridges,  and  rafts/ferries.  The  combinations  of  task  activities  and  facilities 
on  which  they  may  be  performed  are  shown  in  Figure  IV-14-1. 


Facility 

Task  Function/Activitv 

Build 

Breach 

Remove 

Minefield 

X 

X 

X 

Ford 

X 

X 

Bridge 

X 

X 

X 

Raft/Ferry 

X 

X 

Figure  IV-14-1.  Engineer  Task  Activities 


2.  MODEL  DESIGN: 

a.  General.  The  Engineer  Model  simulates  the  scheduling  and  execution 
of  engineer  tasks  and  assesses  delays  incident  to  the  tasks  and  the  related 
barriers  and  facilities.  The  model  accepts  engineer  tasks,  assigns  priorities 
to  them,  determines  task  feasibility,  assigns  resources  according  to  task 
priority,  mobilizes  task  forces,  executes  the  tasks,  reports  results,  demobi¬ 
lizes  the  task  forces,  and  maintains  current  status  information  on  barriers 
and  facilities. 

(1)  Task  Basis.  Engineer  tasks  are  based  upon  pregame  gamer-prepared 
barrier  plans  and  controller-prepared  barrier  guidance.  Such  plans  and 
guidance  are  updated  as  required  at  the  beginning  of  each  game  period. 


(2)  Task.  Initiation: 


(a)  Engineer  tasks  may  be  initiated  by  either  of  two  methods: 

1_.  Gamer  DSL  orders  issued  at  the  beginning  of  a  game  period. 

2_.  Automatic  orders  generated  during  a  game  period  by  the 
Movement  Model  when  a  unit  in  movement  encounters  a  barrier. 

(b)  Although  it  is  not  strictly  an  engineer  task  initiation, 
the  Engineer  Model  is  also  triggered  automatically  by  the  Nuclear  Assessment 
Model  when  a  nuclear  event  results  in  the  creation  of  a  barrier  or  affects 
the  status  of  an  existing  barrier  or  facility. 

(3)  Task  Priority  Assignment.  The  allocation  and  scheduling  of 
resources  for  engineer  tasks  is  based  upon  model  assignment  of  a  three-digit 
task  priority  indicator.  One  of  the  indicator  digits  is  fixed  and  is  based 
upon  preset  game  rules;  the  other  two  digits  are  variable  and  partially  gamer- 
controlled  . 

(A)  Task  Feasibility.  Based  upon  assigned  priority,  each  task 
is  checked  for  feasibility  in  two  areas  ,  resources  and  manpower.  Resource 
and  manpower  feasibility  are  determined  from  a  comparison  of  resources/ 
manpower  required  (preestablished  data  base  specifications)  and  resources/ 
manpower  available. 

(5)  Resource  Allocation.  When  a  task  has  been  passed  for  feasibility, 
resources  are  allocated  or  committed,  and  expendable  equipment  and  supplies 
are  reordered. 

(6)  Task  Force  Mobilization.  An  available  engineer  troop  unit  is 
selected,  required  equipment  and  supplies  are  added  to  the  unit,  and  the 
unit  is  moved  to  the  task  site. 

(7)  Task  Execution.  When  sufficient  resources  are  on  site,  engineer 
task  work  is  started  and  delay  times  are  calculated.  When  the  task  has  been 
completed,  work  is  stopped,  barrier/facility  files  are  updated,  and,  if  other 
models  are  directly  concerned  with  task  completion,  those  models  are  notified 
of  the  completion  results. 

(8)  Task  Force  Demobilization.  Upon  completion  of  the  engineer  task, 
the  engineer  troop  unit,  with  residual  task  equipment  and  supplies,  is  returned 
to  its  parent  unit,  if  possible;  otherwise,  it  is  placed  in  a  stay  mode  at  a 
suitable  location.  If  the  unit  is  returned  to  its  parent  unit,  residual 
equipment  is  returned  to  the  source  unit  from  which  it  was  originally  extracted. 

b.  Design  Philosophy.  The  Engineer  Model  has  been  designed  on  the  basis 
of  integrated  performance  of  functions  which  can  be  described  best  in  terms  of 
its  six  functional  components: 

(1)  An  executive  routine  (ENGR) ,  which  provides  a  means  for  entering 
the  Engineer  Model,  guides  the  action  into  the  proper  subelement  of  the  model, 

IV-14-3 


•  ^  n.  * 


•  •  mmtm* i  v'twr*  ■ 


diverts  engineer  resources  that  arrive  at  the  task  site  after  task  termination, 
and  handles  miscellaneous  tasks  related  to  game  period  termination. 

(2)  A  priority  routine  (EPRIOR) ,  which  assigns  task  priority  to  each 
engineer  task,  maintains  a  dynamic  ordered  list  of  task  priorities  for  each 
force  (Red  and  Blue),  calculates  the  required  starting  time  for  each  task, 
calculates  task  execution  (including  delays)  and  the  resultant  task  completion 
time,  passes  task  priorities  to  the  feasibility  and  update  routines,  and 
advises  the  release  routine  of  reasons  for  termination  of  engineer  tasks. 

(3)  A  feasibility  routine  (EFEASI),  which  determines  the  feasibility 
of  performing  an  engineer  task  as  a  function  of  task  priority,  proximity  to 
the  FEBA,  and  resources  and  time  available,  commits  available  resources  to 
feasible  tasks  in  order  of  priority,  and  generates  movement  orders  for  troop 
units  allocated  to  the  engineer  tasks. 

(4)  An  update  routine  (EUPDAT) ,  which  sets  a  task-in-process  flag 
when  resources  at  the  task  site  are  sufficient  for  starting  work,  provides 
resource  update  information  for  task  units,  updates  manpower  on  a  task  site 
and  mobilizes  more  manpower  if  the  current  amount  is  inadequate  for  the  task, 
calculates  task  performance  rates  and  the  related  portion  of  the  task  completed 
each  clock  period,  enters  updated  task  information  in  the  barrier-facility 
file,  advises  the  release  routine  of  each  task  completion,  and  triggers  the 
release  of  engineer  forces  upon  completion  of  each  task. 

(5)  A  release  routine  (ERELEA)  which,  upon  completion  or  termination 
of  an  engineer  task,  effects  the  demobilization  of  engineer  resources  including 
the  generation  of  movement  orders,  notifies  the  Movement  Model  of  completion 

or  termination  of  tasks  requested  by  that  model,  updates  the  facility  status 
in  the  barrier-facility  file,  and  provides  period  status  for  end-of-period 
barrier  report.  This  routine  also  precludes  reinitiation  of  a  completed  task. 

(6)  A  nuclear  routine  (ENUCLE) ,  handles  the  engineer  aspects 
of  radiological  barriers  created  by  nuclear  events  and  nuclear  effects 
damage  to  existing  barriers/facilities, 

c.  Engineer  Model  Interfaces  with  Other  Models.  The  Engineer  Model 
interfaces  with  the  Movement  Model  and  the  Nuclear  Assessment  Model.  It 
also  makes  use  of  various  elements  of  the  DIVWAG  system  and,  in  particular, 
the  environmental  characteristics  of  the  battle  area. 

(1)  Interface  with  Movement  Model: 

(a)  General.  Since  the  objective  of  barriers/facilities  is  to 
influence  the  mobility  of  troop  units,  an  interface  between  the  Engineer 
Model  and  the  Movement  Model  is  essential.  Through  this  interface,  the 
Movement  Model  interrogates  the  Engineer  Model  to  determine  if  a  mobility 
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move  segment  intersects  a  barrier  line.  If  it  does,  the  Engineer  Model 
provides  additional  information  about  the  barrier  line  to  permit  the  Movemer.c 
Model  to  make  one  of  the  following  choices: 

_1.  Reroute  the  movement  around  the  barrier  segment  if  feasible. 

2.  Reroute  the  movement  to  an  existing  facility  if  feasible. 

2.  Force  the  barrier  if  it  is  an  active  type. 

Request  the  Engineer  Model  to  neutralize  the  barrier  by 
building  a  facility  or  by  breaching  the  barrier  at  the  point  of  intersection. 

'  (b)  Interface  Subroutine: 

1.  When  a  unit  starts  to  move  along  an  order  segment,  the 
Movement  Model  requests  the  Engineer  Model  to  check  the  segment  for  barriers 
(segment  look-ahead  procedure).  Based  on  intelligence  status  information  only, 
the  Engineer  Model  examines  the  order  segment  starting  from  the  near  end  and 
continuing  until  a  barrier  is  found  or  until  the  destination  end  is  reached. 

If  a  barrier  is  found,  the  examination  is  terminated  and  the  Engineer  Model 
provides  the  necessary  barrier  information  to  the  Movement  Model.  The  Movement 
Model  then  makes  its  decision,  continues  the  unit  movement  along  the  new  route 
or  along  the  original  route  toward  the  barrier,  and  requests  the  Engineer 
Model  for  an  engineer  task  if  appropriate.  (In  the  case  of  rerouting,  the 
new  routing  is  used  for  further  checking  purposes.)  If  no  barrier  is  found, 
the  Movement  Model  continues  the  unit  movement  toward  the  destination  end 
of  the  order  segment. 

2_.  Each  time  the  moving  unit  enters  a  new  terrain  cell,  the 
Movement  Model  requests  the  Engineer  Model  to  check  the  cell  for  barriers 
(cell  look-ahead  procedure).  Based  on  physical  status  information  only,  the 
Engineer  Model  examines  that  cell  portion  of  the  move  segment  starting  from 
the  entry  point  and  continuing  until  a  barrier  is  found  or  until  the  exit 
,  point  is  reached.  If  a  barrier  is  found,  the  procedure  in  the  previous  sub- 
.  paragraph  is  followed.  If  no  barrier  is  found,  the  Movement  Model  continues 
the  unit  movement  to  the  exit  point  of  the  terrain  cell. 

_3.  When  a  barrier  is  found  and  rerouting  is  not  feasible, 
the  Movement  Model  continues  the  unit  movement  to  the  point  of  intersection 
with  the  barrier.  There,  the  unit  either  executes  forcing  action  on  the 
barrier  and  continues  movement,  or  it  goes  into  a  stay  mode  until  receipt  of 
further  orders  or  advice  from  the  Engineer  Model  that  the  engineer  task  is 
*  completed.  If  the  Engineer  Model  is  unable  to  accomplish  the  task  and  the 
unit  lacks  conditional  orders,  the  unit  will  remain  in  a  stay  mode  until  the 
•  end  of  the  game  period. 
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(2)  Interface  with  Nuclear  Assessment  Model: 

(a)  General.  Two  major  factors  requiring  interface  between  the 
Engineer  Model  and  the  Nuclear  Assessment  Model  are  the  following: 

_1.  The  employment  of  nuclear  weapons  creates  radiological 
barriers;  for  economy  in  modeling,  it  is  preferable  that  all  barriers  be 
handled  in  a  single  model  (in  this  case,  the  Engineer  Model). 

2_.  Nuclear  effects  may  easily  damage  or  otherwise  modify 
existing  barriers/facilities.  Barriers/facilities  must  be  updated  as  required 
to  reflect  their  current  status. 

(b)  Handling  of  Radiological  Barriers: 

_1.  When  a  nuclear  event  creates  a  radiological  barrier,  the 
Nuclear  Assessment  Model  advises  Engineer  Model  that  a  nuclear  event  has 
occurred,  identifies  the  coordinates  of  ground  zero,  and  specifies  the  radius 
of  the  effective  circular  radiological  barrier.  The  Engineer  Model  then 
establishes  two  barrier  segments  tangent  to  the  circular  barrier  and  perpendi¬ 
cular  to  the  initial  slope  of  the  battlefield . ^  Two  other  barrier  segments 
are  then  added  connecting  the  endpoints  of  the  first  two  and  forming  a  square 
to  encompass  the  barrier.  Each  barrier  segment  is  centered  on  its  point  of 
tangency  and  is  of  a  length  equal  to  twice  the  radius  of  the  radiological 
barrier. ^ 

2.  When  the  Movement  Model  encounters  a  barrier,  it  requests 
information  from  the  Engineer  Model;  if  the  barrier  is  a  radiological  barrier, 
the  Engineer  Model  so  advises  the  Movement  Model  and  indicates  the  extent  of 
the  barrier  encountered.  The  Movement  Model  then  requests  information  from 
the  Nuclear  Assessment  Model  and  is  advised  of  the  radiation  dose  that  will 
be  assessed  if  the  troop  unit  is  moved  through  the  radiological  barrier.  The 
Movement  Model  then  decides  either  to  go  through  and  accept  the  assessment 
or  to  bypass  the  barrier  if  conditions  so  permit . 

_3.  At  specified  periodic  intervals  the  Nuclear  Assessment 
Model  advises  the  Engineer  Model  of  the  decay-reduced  radius  of  the  radiological 
barrier,  and  the  Engineer  Model  updates  the  location  and  extent  of  the  barrier 
segments.  When  the  decayed  radius  of  the  radiological  barrier  is  less  than 
50  meters,  the  barrier  is  considered  of  negligible  effect  and  is  removed. 4 
removed . 


2.  Determined  by  a  line  connecting  the  center  of  mass  of  the  Blue  force 
with  the  center  of  mass  of  the  Red  force  (see  Chapter  5  of  this  section). 

3.  This  length  was  selected  as  an  arbitrary  starting  point.  Future 
operational  sensitivity  tests  should  be  conducted  to  determine  the  proper 
magnitude. 

4.  Fifty  meters  was  selected  as  an  arbitrary  starting  point.  Future 
operational  sensitivity  tests  should  be  conducted  to  determine  the  proper 
magnitude. 
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(c)  Handling  of  Nuclear  Effects  Damage  to  Existing  Barriers/ 

Facilities : 


1_.  When  a  nuclear  event  occurs,  the  Nuclear  Assessment  Model 
advises  the  Engineer  Model,  identifies  the  coordinates  of  ground  zero,  and 
specifies  the  maximum  radius  of  effects  pertinent  to  existing  barriers/ 
facilities.  The  Engineer  Model  checks  the  location  of  existing  barriers/ 
facilities  with  respect  to  the  radius  of  effects  and  identifies  those  lying 
partially  or  wholly  within  this  radius.  The  Engineer  Model  then  identifies 
these  existing  barriers/facilities  to  the  Nuclear  Assessment  Model,  including 
type  and  end-point  coordinates. 

2_.  The  Nuclear  Assessment  Model  considers  each  reported 
barrier/facility,  assesses  damage,  and  advises  the  Engineer  Model  as  to  the 
revised  status  of  each  such  barrier/facility.  The  Engineer  Model  records 
the  damaged  barriers/facilities  and  the  revised  status  of  each.  At  the  end 
of  the  game  period,  these  data  are  output  with  barrier/facility  records  for 
report  purposes. 


3^.  Gamers  examine  the  damage  list  and  update  the  status  of 
these  barriers/facilities,  as  follows:  If  the  character  identification  of  a 
barrier  has  been  changed;  e.g.,  a  forest  changed  to  a  forest  fire  or  to  tree 
blowdown,  the  gamer  replaces  the  original  barrier  identification  with  a  new 
mnemonic  to  indicate  the  new  character  of  the  barrier.  If  only  a  portion  of 
a  barrier  has  changed  character,  the  gamer  divides  the  original  barrier  segment 
into  two  or  more  segments  to  fit  the  new  status  and  defines  these  new  segments. 

(3)  Interface  with  Environmental  Characteristics.  The  Engineer 
Model  interfaces  with  the  following  characteristics  of  the  environment. 

(a)  Terrain: 

1_.  The  Engineer  Model  uses  the  traff icability  indexes  to 
determine  rate  modifiers  to  be  applied  to  engineer  task  performance  rates  to 
account  for  degradation  due  to  variability  of  terrain  at  task  sites. 

2.  The  Engineer  Model  supplements  the  Environment  Model 
by  permitting  identification  of  terrain  features,  forestation,  and  man-made 
facilities  which  significantly  hinder  or  facilitate  force  mobility  in  the 
context  of  barriers  and  facilities.  The  gamer  can  integrate  natural  features 
having  appreciable  effect  on  mobility  (e.g.,  mountains,  dense  forests,  unford- 
able  streams)  into  barrier  lines  of  significant  extent.  Barriers  may  be 
breached  by  facilities  through  engineer  tasks.  For  example,  a  river  barrier 
segment  may  be  breached  by  constructing  a  bridge,  a  raft/ferry,  or  possibly  a 
ford.  Barrier  segments  which  are  unsuitable  for  construction  of  facilities 
are  designated  as  unbreachable;  e.g.,  cliffs  and  rivers  through  marshlands  or 
those  with  steep  rocky  banks. 

(b)  Light  Condition.  The  Engineer  Model  considers  light  effects 
and  uses  day/night  conditions  to  determine  a  rate  modifier  to  be  applied  to 
engineer  task  performance  rates  to  account  for  degradation  due  to  night 
conditions. 
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3.  SUBMODEL  SPECIFICATIONS: 


a.  General.  This  paragraph  examines  each  of  the  major  routines  of  the 
Engineer  Model  and  presents  the  related  logical  flow,  generally  at  the  first 
level  of  detail,  but  at  lower  levels  if  required  for  clarity.  Two  general 
files  are  created  by  the  Engineer  Model  and  used  by  various  routines  in 
processing  engineer  task  requests  and  tasks. 

(1)  Barrier-Facility  File.  The  barrier-facility  file  provides 

the  data  base  for  engineer  operations  as  well  as  working  information  for  the 
Engineer  Model  routines.  In  addition,  it  provides  an  information  base  for 
other  models  and  for  reports  required  by  the  DIVWAG  system.  A  barrier  or 
facility  is  described  in  the  file  in  terms  of  its  sequential  location  in  the 
barrier  line  (previous  and  following  segments),  coordinates  of  its  two  end 
points,  a  mnemonic  identifying  its  type  and  its  unique  number  within  that 
type,  its  size  if  not  a  minefield,  its  density  if  a  minefield,  whether  or 
not  it  is  radioactive  or  has  been  damaged  as  the  result  of  a  nuclear  event, 
its  task-related  requirements  parameters,  and  its  task  status  parameters. 

(2)  Unit  Equipment  File.  The  unit  equipment  file  serves  as  a 
holding  file  for  sources  of  equipment  used  on  engineer  tasks.  It  provides  a 
means  for  returning  equipment  to  sources  when  a  task  is  completed  or 
terminated. 

b.  Engineer  Driver  Routine,  ENGR  (Figure  IV-14-2): 

(1)  Purpose.  The  driver  routine  serves  as  access  to  the  Engineer 
Model;  it  performs  the  following  specific  functions: 

(a)  Guides  the  action  into  the  proper  subelement  of  the  model. 

(b)  Checks  terminated  tasks  and  intercepts  and  diverts  troop 
units  which  are  en  route  to  the  task  site  at  the  time  the  task  is  terminated. 

(c)  Handles  miscellaneous  tasks  related  to  game-period  termination. 

(2)  Relationship  to  Other  Major  Components.  See  Figure  IV-14-2. 

(a)  Inputs  Received: 

1.  DSL  orders  from  gamers. 

2.  Requests  for  engineer  tasks  from  Movement  Model. 

_3.  Barrier  information  related  to  nuclear  events  from 
Nuclear  Assessment  Model. 

U.  Engineer  operating  instructions  from  EFEASI. 
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(b)  Outputs  Produced: 

1.  Unranked  task  and  priority  list  to  EPRIOR. 

2_.  Indication  of  type  action  required  to  ENUCLE. 

(3)  Accessories.  The  driver  routine  uses  data  file  12  as  a  means  for 
breaking  down  DSL  orders  and  other  communications,  both  external  and  internal, 
into  elements  that  can  be  handled  by  the  model. 

c.  Engineer  Priority  Routine,  EPRIOR  (Figure  IV-14-3): 

(1)  Purpose.  The  priority  routine  functions  as  the  first  stage  of 
the  task  filter  by  computing  the  priority  of  all  scheduled  and  unscheduled 
tasks  and  integrating  these  into  a  ranked  priority  list.  It  performs  the 
following  specific  functions: 

(a)  Assigns  a  task  priority  to  each  engineer  task. 

(b)  Maintains  a  dynamic  list  of  task  priorities  for  each  force 
(Blue  and  Red) . 

(c)  Calculates  the  required  starting  time  for  each  task. 

(d)  Calculates  task  execution  time,  including  delays,  and 
calculates  the  resultant  task  completion  time. 

(e)  Provides  to  other  routines  information  on  the  current 
relative  priorities  of  tasks. 

(f)  Provides  to  the  release  routine  information  on  task  termi¬ 
nations. 

(2)  Relationship  to  Other  Major  Components.  See  Figure  IV-14-3. 

(a)  Inputs  Received.  Unranked  task  and  priority  list  from  ENGR. 

(b)  Outputs  Produced: 

1^.  Current  ranked  task  priority  list  to  EFEASI. 

_2.  Current  task  priority  information  to  EUPDAT. 

3.  Indication  of  reason  for  task  termination  (i.e. ,  DSL 
stop  order  or  violation  of  FEBA  constraint)  to  ERELEA. 

(3)  Priority  Determination.  The  allocation  and  scheduling  of 
resources  for  engineer  start  tasks  are  based  upon  model  comparison  of  three- 
digit  task  priority  indicators  as  shown  in  Figure  IV— 14-4.  Stop  tasks 
automatically  receive  top  priority  as  they  release  engineer  resources  for 
start  tasks.  Each  of  the  three  indicator  digits  is  considered  individually. 


Figure  IV-14-3.  Engineer  Priority  Routine,  EPRIOR 
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(a)  Structure  and  Function  Indicator  (A) :  This  indicator  is 
preset  and  is  model-controlled  during  the  game;  its  purpose  is  to  provide 
the  gross  priority  basis  for  all  engineer  start  tasks.  The  value  of  this 
indicator  is  determined  primarily  by  the  urgency  of  che  task.  If  the  task 
is  classified  mandatory,  this  indicator  is  given  a  value  of  1;  if  the  task  is 
classified  desired,  this  indicator  is  given  a  value  ranging  from  2  to  5  as 
shown  in  Figure  IV-14-4,  depending  on  three  secondary  conditions  as  follows: 


defense. 


1.  The  posture  of  the  military  force;  i.e.,  offense  or 


2.  The  type  of  structure  involved;  i.e.,  barrier  or  facility. 

3.  The  nature  of  the  task  function  involved;  i.e.,  build, 

breach,  or  remove. 


(b)  Time  Preference  Indicator  (B).  This  indicator  is  a  variable 
and  is  based  on  the  amount  of  time  remaining  until  the  scheduled  clock  time 
of  the  start  of  a  task.  Its  purpose  is  to  permit  a  shifting  upward  of  the 
priority  of  a  task  as  the  need  for  the  task  becomes  more  imminent. 


(c)  Task  Preference  Indicator  (C).  This  indicator  is  designated 
by  the  gamer.  Its  purpose  is  to  function  as  tie-breaker  and  establish  task 
priority  when  the  A  and  B  priority  indicators  are  identical;  e.g.,  when  two 
or  more  barriers  are  to  be  constructed  at  or  near  the  same  time.  The  gamer 
decides  which  task  should  have  priority  for  resources. 


(d)  Priority  Algorithm.  The  priority  routine  uses  the  following 
algorithm  to  compute  an  overall  task  priority  for  ordering  the  task  priority 
listing: 


PRTY  -  16  *  (FCNPRTY  -1)  +  4  *  (TIMPRTY  -1)  +  DSLPRTY  (IV-14-1) 


where: 


PRTY  indicates  total  or  overall  priority 

FCNPRTY  indicates  the  value  of  the  structure  and 
function  indicator  from  column  A,  Figure  IV-14-4 

TIMPRTY  indicates  the  value  of  the  time  preference 
indicator  from  column  B,  Figure  IV-14-4 

DSLPRTY  indicates  the  value  of  the  task  preference 
indicator  from  column  C,  Figure  IV-14-4. 


This  algorithm  was  designed  to  provide  a  basis  for  ranking  tasks  in 
consonance  with  the  general  priority  scheme. 


IV-14-13 


+  IT* 


(e)  Man-hour  Requirement  Algorithm.  The  priority  routine  uses 
the  following  algorithms  to  compute  man-hour  requirements  for  a  task: 

_1.  If  the  task  type  is  a  minefield: 


where: 


MHR  *  TSKSIZ  *  TSKRAT 


(IV-14-2) 


MHR  “  total  man-hours  required 

TSKSIZ  »  task  size:  length  of  minefield  computed  by  using  the  c'istance 
formula  between  the  two  end  points  of  the  minefield  segment 

TSKRAT  =*  task  rate  taken  from  engineer  task  file. 

2.  If  the  task  type  is  other  than  a  minefield: 


where : 


MHR  -  TSKSIZ  *  TSKRAT  *  PLATMEN  *  PLATNBR  (IV-14-3) 


TSKRAT  «  defined  above 

PLATMEN  »  standard  number  of  men  in  a  platoon  (taken 
in  the  model  as  120  for  troop  type  5,  and 
30  for  all  other  troop  types) 

PLATNBR  »  standard  nuntoer  of  platoons  required  for  this 
task  size,  taken  from  engineer  task  file. 


(f)  Task  Starting  Time.  The  priority  routine  uses  the  following 
algorithms  to  establish  task  starting  time: 

_1.  If  the  task  is  generated  by  a  DSL  order  which  indues  the 
modifier  START  BY  DDTTTT : 


TSTART  ■  DDTTTT  (IV-14-4) 

where : 

TSTART  «=  task  starting  time 

DDTTTT  ■  date-time  group  indicating  start  time 

2.  If  the  task  is  generated  by  a  DSL  order  which  includes 
the  modifier  COMPLETE  BY  DDTTTT: 
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TBASIC  =  (60  *  MHR)  f  (PLATMEN  *  PLATMBR) 


(IV-14-5) 


I  » 


t 


if  cask  type  is  a  minefield,  otherwise: 

TBASIC  =  60  *  TSKSIZ  *  TSKRAT 


(IV-14-6) 


where : 


TBASIC  =*  basic  time  required  for  accomplishing  task 

under  condtions  applicable  to  standard  rates 

TDELTA  -  TBASIC  ~  (RATMODTER  *  RATMDDNIT)  (IV-14-7) 


where : 


TDELTA  ■  time  required  for  accomplishing  task  under 
actual  conditions  with  degraded  rates 

TBASIC  *  defined  above 

RATMODTER  *  terrain  rate  modifier  from  engineer  task  file 

RATM3DNIT  *  night  rate  ncdifier  from  engineer  task  file; 

equals  1.0  if  night  conditions  are  not  involved. 


TSTART  -  TCOMPL  -  TDELTA  -  TBUFFER  (IV-14-8) 


where: 


TSTART  =  defined  above 

TCOMPL  =  DDTTTT  ■  date- time  group  specifying 
completion  time 

TDELTA  »  defined  above 

TBUFFER  *  arbitrary  buffer  time  allocated  to  cover  contingency 
delays;  equals  ^5  minutes  If  task  is  mandatory, 
otherwise  equals  30  minutes. 


3.  If  the  task  Is  generated  by  the  Movement  Model: 


TSTART  *  earliest  time  task  is  found  to  be  feasible. 


d.  Engineer  Feasibility  Routine,  EFEASI  (Figure  IV-14-5): 

(1)  Purpose.  The  feasibility  routine  functions  as  the  second  stage 
of  the  task  filter  and  commits  resources  to  feasible  tasks  in  accordance  with 
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Figure  IV- 14-5.  Engineer  Feasibility  Routine,  EFEASI 
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the  requirements  of  the  task.  It  performs  the  following  specific  functions: 


(a)  Determines  the  current  feasibility  of  performing  an  engineer 
task  based  on  the  current  status  of  task  priority. 

(b)  Commits  available  resources  to  specific  feasible  tasks  in 
order  of  priority  when  the  task  commitment  is  triggered. 

(c)  Generates  movement  orders  for  troop  units  committed  to  tasks. 

(2)  Relation  to  Other  Major  Components.  See  Figure  IV-14-5. 

(a)  Inputs  Received.  Current  ranked  task  priority  list  from 

EPRIOR. 

(b)  Outputs  Produced: 

1_.  Information  on  depletion  of  resources  to  unit  status  file. 
2.  Engineer  operating  instructions  to  ENGR. 

_3.  Movement  orders  for  troop  units  committed  to  tasks  to 

Movement  Model. 

(3)  Feasibility  Determination.  EFEASI  takes  each  task  from  the 
priority  list  by  priorities  from  highest  to  lowest  and,  based  upon  task 
information  in  the  barrier-facility  file,  computes  the  resources  required 
for  each  particular  task.  It  then  compares  resources  required  with  resources 
available;  when  the  latter  are  adequate,  feasibility  is  established. 

(a)  EFEASI  determines  the  troop  requirement  by  examining  the 
troop  type  number  (from  barrier-facility  file;  and  the  standard  number 
required  (from  engineer  task  file) ,  and  using  the  following  algorithm: 

TRREQ  *  (TRUNITA  +  TRUNITB)  *  STD MR  (IV-14-9) 


where : 


TRREQ  »  troops  required  for  task 

TRUNITA  »  troop  unit  A:  one  bridge  platoon  if  troop  type 
number  is  5;  otherwise,  this  is  a  null  unit 

TRUNITB  *  troop  unit  B:  one  combat  engineer  company  if 

troop  type  number  is  5;  otherwise,  one  combat 
engineer  platoon 

STDNR  »  standard  number  of  units  required  for  this  task  type. 
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(b)  EFEASl  determines  the  equipment  and  supply  requirements  by 
examining  the  task  size  and  the  current  physical  status  of  the  barrier  or 
facility  and  using  the  following  algorithms: 


EQPMULT  =  TSKS1NR  -f-  PROPFAC  (IV-14-10) 


where: 


EQPMULT 


TSKSIN'R 


PROPFAC 


equipment  or  supply  multiplier,  a  multiplying 
factor  relating  quantity  of  type  equipment 
or  supply  required  for  this  size  task  to  the 
quantity  required  for  a  standard  size  task 
(this  is  determined  for  each  item  code 
involved) 

task  size  number  determined  by  comparing  task 
size  value  with  task  sizes  found  on  scale  of 
task  sizes  in  engineer  task  file 

proportionality  factor,  a  weighting  factor  used 
for  adjusting  equipment  and  supplies  to  fit 
variable  task  sizes;  taken  from  engineer 
task  file. 


EQPREQ  -  EQPSTD  *  EQPMULT  *  CONFAC  *  RESRAT  *  FACFRAC  (TV-J S  11) 

where : 

EQPREQ  ■  total  quantity  of  a  line  item  equipment  or  supply 
required  for  this  task 

EQPSTD  »  standard  quantity  of  this  line  item  equipment  or 
supply  required  for  basic  size  task 

EQPMULT  ■  defined  above 

CONFAC  -  contingency  factor  tc  provide  a  cushion  for  losses 
due  to  enemy  action;  taken  as  1.05  in  the  model 

RESRAT  -  task  restart  ratio:  1- (MHRCMPLTD/MHRREQ) 

MHRCMPLTD  *  total  man-hours  completed  on  task 

MHRREQ  *>  total  man-hours  required  for  task 

FACFRAC  ■  fraction  of  total  facility  or  barrier  comprising 
task;  following  values  are  used: 
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Task 

Function 

Facility 

Does  Not  Exist 

Facility 

Exists  Intact 

Facility 
Exists  Breached 

Build 

1.00 

0.00 

0.33 

Breach 

0.00 

1.00 

0.00 

Remove 

0.00 

1.00 

0.67 

(A)  Resource  Allocation: 

(a)  EFEASI  selects  and  disperses  the  necessary  resources  for  the 
task,  including  troops,  equipment,  and  supplies.  It  locates  the  nearest 
suitable  troop  units  and  generates  the  movement  orders.  The  Movement  Model 
moves  the  units  to  the  task  site. 

(b)  If  a  task  has  been  found  to  be  infeasible  because  resources 
are  inadequate  to  meet  total  requirements,  but  the  resources  are  adequate 

to  meet  minimum  requirements  for  starting  the  task,  EFEASI  allocates  available 
resources;  this  task  then  has  first  priority  over  similar  tasks  for  new 
resources  when  they  become  available. 

(c)  If  a  task  has  been  found  to  be  infeasible  because  resources 
are  inadequate  to  meet  minimum  requirements  for  starting  the  task,  EFEASI 
sets  an  insufficiency  flag  which  prohibits  allocation  of  resources  to  any 
other  task  of  this  type,  except  a  task  specified  as  mandatory,  until  the 
requirements  of  this  flagged  task  have  been  met. 

e.  Engineer  Update  Routine,  EUPDAT  (Figure  IV-14-6): 

(1)  Purpose.  This  routine  evaluates  every  engineer  activity  in 
progress  and  updates  the  status.  It  performs  the  following  specific  functions 

(a)  Sets  task-in-process  flag  when  resources  on  hand  at  a  task 
site  are  adequate  for  starting  work. 

(b)  Provides  resource  update  information  for  task  units. 

(c)  Updates  manpower  on  a  task  site  and  mobilizes  more  manpower 
if  current  manpower  is  inadequate  for  the  task. 

(d)  Calculates  task  performance  rates  and  the  related  portion  of 
the  task  completed  each  clock  period. 

(e)  Enters  updated  task  information  into  the  barrier-facility 

file. 
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OBTAIN  FROM  CONSTANT  DATA  BASE 
FORCE  TO  EXECUTE  ,  BARRIER  TYPE 
ANO  ID,  TROOP  TYPE  ANO  STANOARO 
NUMBER  REQUIRED,  CURRENT  NUMBER 
OF  MEN  WORKING,  TASK  RATE,  AND 
TERRAIN  AND  LIGHT  RATE 
MODIFIERS 

f 


CALCULATE  TIME  SINCE  LAST  UPOAT6 
_  AND  NEW  TASK  RATE 


~SUM  UP  AMOUNT  OF  EQUIPMENT 
AND  SUPPLIES  ON  HANO, 
INCLUDING  FOOO  ANO  POL 

J 


based  upon  amount  on  hand 

V.  STANOARO  AMOUNT  NEEOEO, 
CALCULATE  EQUIPMENT 
RATE  MODIFIERS 


DETERMINE  FOOO  AND  POL  USED 
SINCE  LAST  UPOATC ;  REDUCE; 


AND  REORDER  IF  NEEDED 

; 

DETERMINE  EXPENDABLE  EQUIPMENT 
AND  SUPPLIES  USED 

SINCE  LAST  UPDATE,  REDUCE; 

AND  REORDER  l  F  NEEDED 

Figure  IV-14-6.  Engineer  Update  Routine,  EUPDAT 
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(f)  Advises  the  release  routine  of  each  task  completion  and 
triggers  the  release  of  engineer  forces  upon  completion  of  each  task. 

(2)  Relation  to  Other  Major  Components:  See  Figure  IV-14-6. 

(a)  Inputs  Received.  Resources  allocated  to  a  task  from  EFEASI 
(indirectly  through  the  Movement  Model) . 

(b)  Outputs  Produced: 

JL.  Update  information  on  task  status  to  unit  status  file, 
unit  equipment  file,  and  barrier-facility  file. 

2.  Task  completion  information  and  triggering  for  demobil¬ 
ization  of  task  units  to  ERELEA. 

(3)  Update  Procedures: 

(a)  EUPDAT  reevaluates  the  priorities  of  all  tasks  the  model 
has  requested  except  those  with  priority  5000,  examines  resources  versus  time 
remaining  to  complete  the  task,  and  reallocates  resources  to  tasks  in  progress 
until  they  have  their  full  quotas  of  resources. 

(b)  EUPDAT  decrements  ,  in  most  cases,  the  proper  item  codes  by 
the  amount  expended  since  the  last  previous  update  and  outputs  updated 
information  to  the  barrier-f acility  file. 

(4)  Update  Algorithms.  The  update  routine  uses  the  following 
algorithms  to  compute  man-hours  expended  for  updating  of  the  barrier-facility 
f  ile: 


TSKRATAD  =  TSKRAT  4  (RATMODTER  *  RATMODNIT  *  RATMODEQP)  (IV-14-12) 


where : 


TSKRATAD  *  adjusted  task  rate 

TSKRAT  -  task  rate  taken  from  engineer  task  file 
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RATMODTER  *  terrain  rate  modifier  from  engineer  task  file 

RATMODNIT  =  night  rate  modifier  from  engineer  task  file; 

equals  1.0  if  night  conditions  are  not 
involved 

RATMODEQP  =  product  of  equipment  rate  modifiers  for  equipments 
involved  in  task;  individual  modifiers  are 
taken  from  engineer  task  file. 


TPROP  =  TELAP  r  TSTDPD 


(IV- 14- 13) 


where : 


TPROP  *  time  proportion;  i.e.,  fraction  of  a  standard  time 
period  that  has  passed  since  last  update 

TELAP  =  elapsed  time  since  last  update 

TSTDPD  =  standard  time  period;  15  minutes  is  taken 
in  Engineer  Model. 


MHREXP  = 


_ TPROP  *  TSKSIZ  *  MENNBR _ 

TSKRATAD  *  PLATNBR  *  PLATMEN  *  STDPDPHR 


(IV-14-14) 


where : 

MHREXP  *  total  man-hours  expended  since  last  update 

TSKSIZ  *  task  size  (as  computed  for  minefields,  or 
as  taken  from  barrier- facility  file  for 
other  type  tasks) 

MENNBR  =  actual  number  of  men  in  units  assigned  to 
task  site 

TSKRATAD  -  defined  above 

PLATNBR  =  standard  number  of  platoons  required  for  this 
task  size,  taken  from  engineer  task  file 

PLATMEN  =  standard  number  of  men  in  a  platoon  (taken  in 
the  model  as  120  for  troop  type  5,  and  30 
for  all  other  troop  types) 
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STDPHPHR  =  number  of  standard  time  periods  per  hour,  taken 
as  4  in  the  model. 

f.  Engineer  Release  Routine,  ERELEA  (Figure  IV- 14-7): 

(1)  Purpose.  This  routine  demobilizes  mission  units  and  resources 
whenever  there  is  reason  for  stopping  a  task,  it  performs  the  following 
specific  functions: 

(a)  Terminates  tasks  when  tasks  are  completed,  when  a  DSL  stop 
order  is  received,  or  when  a  specified  FEBA  condition  exists. 

(b)  Generates  movement  orders  for  demobilization  of  task  troop 
units  when  a  task  is  completed  or  terminated. 

(c)  Notifies  Movement  Model  of  completion  or  termination  of 
tasks  requested  by  that  model. 

(d)  Updates  facility  status  in  barrier- facility  file  on  completion 
or  termination  of  task. 

(e)  Provides  period  status  for  end-of-period  barrier  report. 

(f)  Removes  completed  tasks  from  the  task  priority  list. 

(2)  Relation  to  Other  Major  Components.  See  Figure  IV-14-7. 

(a)  Inputs  Received: 

JL.  Indication  of  reason  for  task  termination:  i.e.,  DSL  stop 
order  or  violation  of  FEBA  constraint  from  EPRIOR. 

2..  Task  completion  information  and  triggering  for  demobili¬ 
zation  of  task  units  from  EUPDAT. 

(b)  Outputs  Produced: 

1.  Facility  status  update,  both  physical  and  intelligence  to 
barrier-facility  file. 

,2.  Removal  of  completed  task  from  task  priority  list  to 

EPRIOR. 


.3.  To  Movement  Model: 

a.  Movement  order  for  task  troop  units  requiring 

demobilization . 
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(  RETURN  ^ 


Figure  IV-14-7.  Engineer  Release  Routine,  ERELEA 


IV-14-24 


b_.  Task  completion  notice  for  tasks  requested  by  the 

Movement  Model. 

—•  Period  status  to  end-of-period  barrier  report. 

(3)  Release  Procedures: 

(a)  Two  conditions  are  cause  for  release  action:  a  task  is 
completed,  or  a  DSL  order  is  a  stop  order.  In  either  of  these  cases, 
immediate  priority  is  given  to  ERELEA  with  the  reason  for  termination. 

(b)  ERELEA  generates  movement  orders  for  released  units;  Movement 
Model  returns  these  units  to  their  parent  units. 

(c)  ERELEA  incorporates  the  task  status  information  into  the 
barrier-facility  file  and,  if  the  task  was  one  requested  by  the  Movement 
Model,  advises  that  model  of  the  task  status. 

g.  Engineer  Nuclear  Routine,  ENUCLE  (Figure  IV- 14-8) : 

(1)  Purpose.  This  routine  handles  the  Engineer  Model  aspects  of 
radiological  barriers  created  by  nuclear  events  and  tuclear  effects  damage 

to  existing  barriers/facilities.  It  performs  the  following  specific  functions 

(a)  Establishes,  updates,  or  removes  radiological  barriers  as 
appropriate  when  furnished  nuclear  event  information  or  update  information. 

(b)  Notifies  Nuclear  Assessment  Model  of  existing  barriers  lying 
partially  or  wholly  within  the  radius  of  effects  of  nuclear  events. 

(c)  Records  reported  nuclear  effects  damage  to  existing  barriers/ 
facilities  and  outputs  this  information  for  report  purposes. 

(2)  Relation  to  Other  Major  Components.  See  Figure  IV-14-8. 

(a)  Inputs  Received: 

1^.  Indication  of  type  action  required  from  ENGR. 

2.  From  Nuclear  Assessment  Model: 

a.  Notification  of  nuclear  events  and  their  descriptions, 
b^.  Update  information  for  radiological  barriers. 

£.  Assessed  nuclear  effects  damages  to  existing  barriers/ 

facilities . 
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ENUCLE 
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DETERMINE 
EXISTING  BARRIERS 
AFFECTED 

i  T_ 

PROVIDE  LIST  OP 
AFFECTED  BARRIERS 
TO  RAM  ANO  INDICATE  PART 
OR  TOTAL  ENCLOSURE 

T  '  I 

generate  two  new 
BARRIER  RECORDS  FOR 
THIS  NUCLEAR  EVENT 
TANGENT  TO  EFFECTS 
CIRCLE _ 


ON  BARRIER  FILE 
INDICATE  THESE 
BARRIERS  TO  BE 

radiological 


PERIODICALLY  SIMULATE 
RADIOLOGICAL  DECAY  OF 
RADIOLOGICAL  BARRIERS 
BY  SHRINKING  A  NO 
CONTRACTING  THEM 


REMOVE  OLD  BARRIER 

AND  REPLACE  IT  WITH 

UPOATEO  BARRIER 

ON  BARRIER  FILE 
INDICATE  NUCLEAR 
EVENT  DAMAGE 
ASSESSED  BY  NAM 
ANO  REVISED  STATUS 
OF  AFFECTED  BARRIERS 


RETURN  ^ 


Figure  IV-14-8.  Engineer  Nuclear  Routine,  ENUCLE 
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(b)  Outputs  Produced: 

List  of  barriers/facilities  lying  partially  or  wholly 
within  the  radius  of  effects  of  a  nuclear  event  to  Nuclear  Assessment  Model. 

2_.  Status  of  barriers/facilities  damaged  by  nuclear  effects 
for  end-of-period  barrier  report. 

(3)  Procedures.  Details  of  the  procedures  involved  are  covered  in 
the  discussion  of  the  interface  between  the  Engineer  Model  and  the  Nuclear 
Assessment  Model,  subparagraph  2c (2)  above. 
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APPENDIX  A 


ENGINEER  MODEL  INPUT  REQUIREMENTS 


1.  INTRODUCTION.  This  appendix  describes  the  data  input  requirements  for  the 
Engineer  Model,  which  is  concerned  with  barriers  and  facilities  that  influence 
troop  movements,  the  time  delays  resulting  therefrom,  and  the  engineer  troops 
and  equipments  that  create  or  modify  these  barriers  and  facilities.  The  loading 
of  the  Engineer  Model  data  base  is  not  dependent  on  the  loading  of  any  other 
data  base. 

a.  Data  Requirements.  The  general  types  of  data  required  by  the  Engineer 
Model  Include:  locations  and  characteristics  of  existing  and  planned  barriers, 
locations  and  characteristics  of  existing  and  planned  facilities  for  neutral¬ 
izing  the  barriers,  type  and  magnitude  of  engineer  tasks  related  to  the 
barrier  and  facilities,  equipment  and  personnel  requirements  for  the  engineer 
tasks,  and  rates  of  task  performance  by  different  types  of  engineer  troops. 

t 

b.  Appendix  Contents.  The  contents  of  this  appendix  are  intended  to 
facilitate  understanding  of  the  requirements  and  procedures  for  preparing  the 
constant  data  base  for  the  Engineer  Model.  Paragraph  1  provides  an  overview 

of  this  appendix  and  the  data  base  requirements.  Paragraph  2  provides  detailed 
instructions  for  loading  data  related  to  barriers  and  facilities,  and  paragraph 

3  provides  instructions  for  loading  data  related  to  engineer  tasks.  Paragraph 

4  describes  the  Engineer  Model  data  deck  structure. 

c.  Data  Base  Files.  The  Engineer  Model  uses  five  data  files  as  follows: 

(1)  Barrier  and  Facility  File  (Data  File  2).  This  file  serves  as 
the  repository  for  information  on  barrier  and  facility  characteristics,  loca¬ 
tions  and  status.  This  information  is  also  used  by  the  Movement  Model  and  the 
Nuclear  Assessment  Model,  and  for  the  end-of-point  barrier  and  facility  report. 

(2)  Engineer  Task  File  (Data  File  17).  This  file  identifies  engineer 
tasks  (minefields,  fords,  bridges,  and  rafts/ferries)  and  contains  such 
engineer  task  information  as  size,  equipment  and  troops  required  to  perform 
the  task,  and  rates  of  performance.  This  information  is  for  internal  use  of 
the  Engineer  Model  only. 

(3)  Engineer  Task  Priority  File  (Data  File  18).  This  file  contains 
engineer  task  priorities  and  priority  related  factors.  This  information  is 
for  internal  use  of  the  Engineer  Model  only. 

(4)  Engineer  Task  Site  File  (Data  File  22).  This  file  is  created  from 
data  file  2  and  serves  as  the  repository  for  eight-character  mnemonics  comoris- 
ing  the  task  site  quadrature  for  searching  for  and  locating  task  sites.  This 
information  is  also  used  by  the  Movement  Model. 


(5)  Engineer  Equipment  File  (Data  File  37).  This  file  serves  as  the 
repository  for  information  as  to  the  source  of  equipment  mobilized  at  engineer 
task  sites.  This  information  is  for  internal  use  of  the  Engineer  Model  only. 

2.  DATA  BASE  FOR  BARRIERS  AND  FACILITIES.  The  barrier  and  facility  data  base 
serves  as  the  basic  information  source  for  engineer  operations  and  tasks  and 
is  derived  from  barrier  planning.  At  the  division  level  this  planning  is 
based  on  guidelines  and  information  provided  in  corps  and  field  army  barrier 
plans.  Barrier  and  facility  data  include  the  characteristics  and  location 
of  each  barrier  segment,  the  type  of  engineer  tasks  associated  therewith, 
and  the  current  status  of  the  segment.  The  player  teams  of  opposing  forces 
prepare  barrier  lines  appropriate  to  the  tactical  situation.  If  the  game 
to  be  played  is  an  open  game,  preparation  of  barriers  common  to  both  forces 
is  facilitated  if  the  two  player  teams  prepare  their  barrier  line  cooperatively. 
The  load  routine  for  barriers  and  facilities  involves  three  cards.  Preparation 
of  each  card  is  discussed  in  the  following  subparagraphs. 

a.  Barrier  System  Location  (Card  ID  0200).  This  card,  illustrated  in 
Figure  IV-14-A-1,  sets  up  a  quadrature  system  for  the  model  to  use  in  keying 
in  all  barrier  and  facility  locations.  One  card  is  prepared  pregame,  normally 
by  the  Control  Team,  and  the  data  therein  remain  fixed  throughout  the  game. 

All  numbers  in  the  card  are  to  be  right  justified. 

(1)  Card  Type  and  Force  Designator  (Columns  1-2).  In  column  1  the 
number  1  is  preprinted  to  indicate  the  card  type.  In  column  2  enter  "B"  since 
the  quadrature  system  is  force  independent. 

(2)  Geographical  Area  (Columns  4-19).  Enter  maximum  X  and  Y 
coordinates  (not  to  exceed  seven  numerals  for  each  X  and  Y  coordinate)  of  the 
geographical  area  representing  the  gaming  area  of  interest. 

(3)  Battle  Area  (Columns  23-38).  Enter  X  and  Y  coordinates  of  the 
geographical  point  estimated  to  be  the  center  of  the  battle  area  at  the  start 
of  the  game;  i.e.,  the  approximate  center  of  the  FEBA. 

b.  Barrier  Line  Identification  (Card  ID  0201): 

(1)  Card  Description.  This  card,  illustrated  in  Figure  IV-14-A-2, 
provides  an  identification  for  each  barrier  line  and  a  structure  for  joining 
and  manipulating  the  barrier  segments.  Standard  naming  of  all  barriers  to  be 
played  with  all  pertinent  information  to  barriers  is  prepared  pregame.  The 
information  is  put  into  the  proper  input  format  to  be  loaded.  Updating  and  re¬ 
moval  of  barrier  lines,  as  well  as  loading  new  lines,  may  be  externally  effected 
between  game  periods. 

(2)  Preliminary  Preparations.  Display  all  ''arrier  lines  on  the 
operations  map.  Select  a  scheme  for  naming  the  lines  that  will  facilitate 
easy  reference  during  gaming.  Assign  a  name  not  exceeding  eight  characters 

to  each  continuous  barrier  line.  For  barrier  continuity  reasons,  intersecting 
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BARRIER  SYSTEM  LOCATION 


BARRIER  LINE  IDESTIFICATIO: 


barrier  lines  should  not  be  terminated  or  segmented  on  the  intersection.  To 

avoid  leaving  a  gap,  a  line  that  would  normally  terminate  at  an  intersection 

must  be  carried  through  the  intersection  and  terminated  on  the  far  side  of  the 
intersection.  A  gap  in  the  barrier  line  will  create  a  discontinuity;  hence, 

unique  names  will  be  required  for  the  barrier  lines  on  opposite  sides  of  the 

gap.  One  method  that  can  be  used  to  avoid  such  a  discontinuity  gap  is  to  provide 
,  for  a  minefield  task  in  the  gap.  The  physical  status  code  in  card  ID  0202 

(subparagraph  c  below)  shows  that  the  field  is  empty  and  permits  units  to  pass 
through  unaffected  unless  the  minefield  is  actually  built  at  some  later  time. 

If  gaps  do  occur,  it  is  recommended  that  the  basic  line  name  be  retained  and 
uniqueness  be  attained  with  numbers;  for  example,  a  line  with  two  gaps  might 
have  subline  names  as  follows: 

•  ALPHA-01  (gap)  ALPHA-02  (gap)  ALPHA-03 

(3)  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  1  is 
preprinted  in  column  1  to  indicate  card  type.  In  column  2  enter  "R"  for  Red 
force  or  "B"  for  Blue  force. 

(4)  Action  (Columns  3-6).  Select  and  enter  one  of  the  following 
action  codes:  LOAD,  REMV  (remove),  UPDT  (update). 

(a)  LOAD: 

1.  Identification  (Columns  9-16).  Enter  the  name  selected  for 
each  unique  barrier  line. 

2.  Game  or  Period  Load  (Columns  19-24),  If  this  line  is  to 
be  loaded  between  game  periods,  PERIOD  should  be  entered;  if  this  is  the  pre¬ 
game  load,  nothing  need  appear. 

(b)  REMV.  Columns  9-14  should  contain  the  mnemonic  of  the  first 
barrier  segment  of  the  line  to  be  removed.  No  differentiation  is  made  between 
game  or  period  removal. 

(c)  UPDT.  Again  columns  9-14  contain  the  mnemonic  of  the  partic¬ 
ular  barrier  segment  to  be  updated.  This  is  followed  by  only  one  card  type 
0202,  then  by  an  end-of-data  card  or  another  card  type  0201. 

(5)  Identification  (Columns  9-16).  Enter  the  name  selected  for  each 
unique  barrier  line. 

c.  Barrier  Segment  Details  (Card  ID  0203): 

(1)  Card  Description,  This  card,  illustrated  in  Figure  IV-14-A-3, 

,  provides  details  as  to  the  location  and  nature  of  barrier  segments,  related 
tasks,  and  the  status  of  such  tasks.  One  card  is  prepared  pregame  for  each 
segment  of  a  barrier  line  the  Control  Conflicting  aspects  of  barriers  on  the 
borderline  between  opposing  forces  are  coordinated.  Task  status  is  updated 
by  the  model.  External  update  or  removal  of  data  may  be  effected  between  game 
periods  with  the  same  constraint  as  indicated  in  subparagraph  b(l)  above. 

t 
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BARRIER  SLCKI.NI  DETAILS 


(2)  Preliminary  Preparations.  Divide  each  barrier  line  into  segments 
that  are  homogeneous  within  the  segment. 

(a)  Two  conflicting  objectives  are  encountered  in  this  process: 
the  objective  of  having  the  line  approximate  closely  the  real  terrain  features, 
which  tends  to  shorten  the  segments  and  increase  their  numbers;  and  the  objective 
of  minimizing  the  effort  and  time  involved  in  game  preparation,  which  tends  to 
lengthen  the  segments.  Judgment  should  be  used  in  reaching  a  reasonable  com¬ 
promise  between  these  objectives. 

(b)  Each  facility,  such  as  a  bridge,  requires  a  unique  line  segment 
in  order  that  a  movement  segment  in  the  Movement  Model  may  intersect  a  finite 
facility  line  segment  rather  than  trying  to  intersect  a  point  location.  If  the 
movement  segment  intersects  the  facility  segment  anywhere,  and  the  facility 
exists,  the  unit  being  moved  is  permitted  to  utilize  the  facility  and  pass 

the  barrier  which  the  facility  is  neutralizing.  The  length  of  the  facility 
segment  will  be  influenced  by  the  character  and  requirements  of  the  adjacent 
segments.  If  conditions  permit,  the  length  of  a  facility  segment  should  be  not 
less  than  100  meters  and  not  more  than  400  meters. 

(c)  River  lines  that  constitute  barriers  offer  more  complexities 
than  other  types  of  natural  features.  A  river  line  segment  may  be  classified 
in  several  different  ways  depending  upon  its  crossing  suitability  or  the  type  ' 
of  facility;  only  one  designator  may  be  used  for  a  segment: 

.  Fords  and  fording  sites  -  mnemonic  BFDXXX 

.  Floating  bridges  and  floating  bridge  sites  -  mnemonic  BFLXXX 
.  Rafts/ferries  and  raft/ferry  sites  -  mnemonic  BFRXXX 
.  Fixed  bridges  and  fixed  bridge  sites  -  mnemonic  BFXXXX 
.  Unsuitable  for  crossing  -  mnemonic  RIVXXX. 

(d)  All  numbers  entered  in  the  card  form  are  to  be  right  justified. 

(3)  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  1  is 
printed  in  Column  1  to  Indicate  card  type.  In  column  2  enter  "R"  for  Red 
force  or  "B"  for  Blue  force. 

(4)  Barrier  Segment  Mnemonic  (Columns  3-8).  Select  one  barrier  line. 
Starting  at  one  end  of  the  barrier  line  and  progressing  sequentially  one  segment 
at  a  time  to  the  other  end,  enter  the  mnemonic  for  each  barrier  segment  (see 
Figure  IV-14-A-4  for  a  list  of  mnemonics).  In  this  way,  the  second  end  point 
coordinates  (X2,  Y2)  for  one  segment  will  become  the  first  end  point  coordinates 
(Xi,  Yl)  for  the  next  succeeding  segment.  (Do  not  exceed  seven  numerals  for 
each  X  and  Y  coordinate.)  After  the  last  segment  in  this  barrier  line,  an 

end  card  is  used  to  signal  the  end  of  the  barrier  line.  This  card  is  prepared 
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Maximum6 

Mnemonic3 

Description 

Status*5 

DSLC 

Unbreach'* 

Number 

ARHXXX 

Helicopter  Pad 

0 

50 

ARLXXX 

Air  Landing  Strip 

0 

BFDXXX 

Ford 

X 

X 

loO 

BFLXXX 

Floating  Bridge 

X 

X 

100 

BFRXXX 

Raft 

X 

X 

250 

BFTXXX 

Foot  Bridge 

0 

X 

50 

BFXXXX 

Fixed  Bridge 

X 

X 

350 

CRTXXX 

Crater 

0 

X 

100 

DFLXXX 

Defile 

0 

100 

FRDXXX 

Tree  Blow-down 

X 

X 

100 

FRFXXX 

Forest  Fire 

X 

X 

100 

FRJXXX 

Jungle 

X 

X 

50 

FRSXXX 

Forest 

X 

X 

500 

FRUXXX 

Undergrowth 

X 

X 

25 

HUMXXX 

Town,  Built-up  Area1 

X 

200 

LDAXXX 

Mountain,  Hill,  Depression 

X 

X 

100 

LDLXXX 

Linear  Land  Barrier  (Cliff,  Canyon, 

X 

X 

100 

etc.) 

MNAXXX 

Minefield ,  Antitank -Antipersonnel 

X 

X 

500 

MNPXXX 

Minefield,  Antipersonnel 

X 

X 

200 

MNTXXX 

Minefield,  Antitank 

X 

X 

200 

MUNXXX 

Munition,  Atomic  Demolition 

0 

MUCXXX 

Radiological  Barrier 

0 

150 

PTHXXX 

Road  or  path 

0 

100 

RIVXXX 

Unbreachable  River  Segment 

X 

X 

300 

SWPXXX 

Swamp 

X 

X 

50 

WTAXXX 

Ocean,  Sea,  Lake 

X 

X 

100 

WTLXXX 

Linear  Water  Barrier  (Canal,  etc.) 

X 

Y 

A 

50 

a.  Enter 

unique  numerical  identifier  in  spaces  marked  XXX. 

b.  X  indicates  available  in  model  and  may  be 

used  in 

current  phase  plav. 

0  indicates  available  in  model  but  will  not  be  used  in  current  phase 

of  play. 

Blank  indicates  not  yet  fully  programmed. 

c.  X  indicates  requirement  for  explicit  DSL  order. 

d.  X  indicates  a  barrier  segment  unbreachable 

for  surface 

mobility. 

e.  Maximum  number  of  this  type  provided  by  the  model 

for  one  game. 

f  •  Towns 

are  barriers  to  surface  movement.  Roads  through 

towns  provide  con- 

stricted  surface  travel  at  reduced  rates,  hence  the  normal  physical  status  of 

a  town  is 

that  of  a  breached  barrier;  i.e.,  code  1  (see  subparagraph  2c(7)). 

Figure  IV-14-A-4.  Barrier  Segment  Mnemonics  Applicable  to  Engineer  Model 
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by  making  an  entry  of  minus  one  (-1)  in  the  coordinate,  with  the  minus 
sign  in  column  16  and  the  1  in  column  17.  (End  cards  do  not  have  any  other 
entries  except  a  card  ID  and  a  card  sequence  number.)  After  completion  of 
the  first  barrier  line,  repeat  the  above  procedures  for  successive  barrier 
lines  until  all  segments  of  all  barrier  lines  have  been  entered. 

(5)  Barrier  Segment  End  Point  Coordinates  (Columns  11-44).  This 
field  defines  the  location  and  length  of  the  barrier  segment  by  listing  the 
coordinates  of  the  two  end  points  of  the  segment.  The  field  is  divided  into 
four  equal  subfields  of  seven  columns  each.  The  first  two  subfields  provide 
space  for  the  Xi  (Columns  11-17)  and  Y]_  (Columns  20-26)  coordinates  of  the 
first  end  point  of  the  barrier  segment,  and  the  third  and  fourth  subfields 
provide  space  for  the  X2  (Columns  29-35)  and  Y2  (Columns  38-44)  coordinates 
of  the  second  end  point.  Do  not  exceed  seven  numerals  for  each  X  and  Y 
coordinate.  When  the  first  end  point  of  a  segment  is  identical  to  the  last 
end  point  of  the  previously  defined  segment,  no  entry  is  required  in  columns 
11-26. 


(6)  Blue  Task  (Columns  46-55).  This  field  defines  a  Blue  task 
related  to  the  barrier  segment.  The  field  is  divided  into  three  subfields. 

(a)  Task  Type  Number  (Columns  46-47).  If  the  barrier  segment 
is  an  unbreachable  natural  barrier,  enter  zero  in  these  columns  and  leave 
the  other  two  subfields  blank;  otherwise,  enter  the  appropriate  task  type 
number  (see  subparagraph  3a(2),  below,  for  an  explanation  of  task  type  numbers). 

(b)  Task  Size  (Columns  49-53).  For  all  tasks  except  minefields, 
enter  the  task  size.  Task  size  for  fords  is  total  length  of  the  ford  (one 
vehicle  lane  assumed  unless  otherwise  specified) ;  task  size  for  bridges  is 
total  length  of  the  bridge  (one  vehicle  lane  assumed  unless  otherwise  speci¬ 
fied);  and  task  size  for  rafts  and  ferries  is  the  total  length  of  the  number 
of  rafts  or  ferries.  For  minefields  the  model  calculates  task  size  from  the 
coordinates;  therefore,  in  lieu  of  task  size,  enter  the  number  corresponding 
to  the  density  of  mines  in  the  minefield  (see  subparagraph  3a(8),  below,  for 
an  explanation  of  density  numbers). 

(c)  Troop  Type  (Column  55).  This  data  item  is  the  troop  type 
associated  with  task.  Enter  the  corresponding  unit  number,  from  1  to  5,  asso¬ 
ciated  with  the  troop  type  (see  subparagraph  3c(2)(b),  below,  for  an  explana¬ 
tion  of  troop  type  numbers). 

(7)  Status  (Columns  58-60).  This  field  provides  the  current  status 
of  the  engineer  task  or  facility  related  to  the  barrier  segment.  The  model 
updates  the  physical  status  as  appropriate  during  the  game.  The  field  pro¬ 
vides  two  single  column  subfields,  the  first  being  for  the  current  physical 
status  of  the  task  or  facility,  and  the  second  being  for  the  current  intelli¬ 
gence  status. 
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(a)  Physical  Status  (Column  58).  In  this  column  enter  code  2 
if  the  task  type  is  0;  otherwise,  enter  the  appropriate  code  number  from  the 
following  list: 


Code 


Definition 


0  Facility  does  not  currently  exist.  This  code 

includes  four  possible  cases: 

.  Task  has  not  been  started 

.  Task  has  been  started  but  is  still 
in  process. 

.  Task  has  been  started  but  has  since 
been  stopped  by  a  stop  order. 

(In  this  case,  a  new  build  order 
will  be  able  to  complete  the  task 
based  upon  the  percentage  of  the 
original  task  remaining  incompleted 
at  the  time  the  stop  order  became 
effective. ) 

.  Task  was  completed  but  facility  was 
subsequently  removed  completely  by 
a  completed  remove  order. 

1  Facility  has  been  completed  and  subsequently 
disrupted  (breached);  it  is  currently  disrupted. 

A  disrupted  facility  may  be  restored  to  complete¬ 
ness  by  a  new  build  order.  (This  will  require 

33  percent  of  the  original  task  effort.)  A 
disrupted  facility  may  be  removed  completely  by 
a  remove  order.  (This  will  require  67  percent 
of  the  task  effort  for  removal  of  the  complete 
facility.)  The  model  effects  calculation  of  the 
percentage  task  requirements  in  both  cases. 

2  Facility  has  been  completed  and  is  currently 
intact  and  serviceable. 


(b)  Intelligence  Status  (Column  60).  In  this  column  enter  code  3 
if  the  task  type  is  0;  otherwise,  enter  the  appropriate  code  number  from 
the  following  list: 
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Code 


Definition 


0  Neither  force  knows  the  current  status  of  the 

barrier  or  facility 

1  Blue  force  knows  but  Red  force  does  not  know  the 
current  status  of  the  barrier  or  facility 

2  Red  force  knows  but  Blue  force  does  not  know  the 
current  status  of  the  barrier  or  facility 

3  Both  forces  know  the  current  status  of  the 
barrier  or  facility. 

The  model  will  update  the  intelligence  status  as  appropriate  during  the  game. 
Knowledge  of  the  status  implies  knowledge  of  existence. 

(8)  Red  Task  (Columns  63-72).  This  field  defines  a  Red  task  related 
to  the  barrier  segment.  Instructions  for  completing  these  data  items  are 
analogous  to  those  for  Blue  (Columns  46-55). 

3.  DATA  BASE  FOR  ENGINEER  TASKS.  The  engineer  task  data  base  serves  to  scale 
resource  requirements  to  fit  engineer  tasks  encountered.  The  data  base  is 
derived  from  analyses  of  engineer  TOE  unit  equipment,  missions,  functions, 
and  capabilities,  and  from  other  military  publications  delineating  engineer 
equipment,  tasks,  and  task  rates.  Engineer  task  data  consist  of  engineer 
task  types,  including  sizes  and  densities;  troop,  equipment,  and  supply 
requirements  for  task  execution;  and  task  performance  rates  and  rate  modi¬ 
fiers.  If  a  game  using  the  DIVWAG  System  is  to  be  an  open  game,  analysis  and 
comparative  evaluation  of  engineer  operations  is  facilitated  if  Red  and  Blue 
engineer  tasks  are  prepared  cooperatively  and  simultaneously,  using  the  same 
task  type  numbers  for  like  tasks  and,  insofar  as  practicable,  making  the  type 
operations  of  one  force  the  mirror  image  of  those  of  the  other  force.  The 
load  routine  for  engineer  tasks  involves  seven  cards.  Preparation  of  each 
card  is  discussed  in  the  following  subparagraphs. 

a.  Task  Identification  (Card  ID  1701): 

(1)  Card  Description.  Card  ID  1701,  illustrated  at  Figure  IV-14-A-5, 
identifies  all  engineer  type  tasks  that  the  model  will  be  capable  of  simulat¬ 
ing  and  establishes  a  grid  matrix  of  sizes  and  densities  to  function  as  a 
control  scale.  One  card  for  each  type  task  is  prepared  pregame,  and  the  data 
therein  remain  fixed  throughout  the  game. 

(2)  Preliminary  Preparations.  Determine  constraints  on  engineer 
operations  and  make  a  working  list  of  the  type  task  that  will  be  permitted. 
Arrange  tasks  in  a  logical  order  with  grouping  of  similar  type  tasks;  e.g., 
all  minefield  Cypes,  and  all  gap  and  stream  crossing  types.  Assign  a  task 
type  number  to  each  task  according  to  the  following  guidelines: 


t 
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.  Numbers  from  1  through  25  may  be  used. 

.  Numbers  from  1  through  4  are  reserved  as  follows: 

1  -  Minefield,  antitank  (AT) 

2  -  Minefield,  antipersonnel  (AP) 

3  -  Minefield,  AT  plus  AP 

4  -  Open,  reserved  for  special  type  of 

mines  or  minefields 

.  Other  numbers  need  not  be  consecutive. 

All  numbers  in  the  card  are  to  be  right  justified. 

(3)  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  1  is 
printed  in  Column  1  to  indicate  card  type.  In  column  2  enter  "R"  for  Red 
force  or  "B"  for  Blue  force. 

(4)  Task  Type  Number  (Columns  3-4).  Enter  task  type  number  from  1 
to  25  as  determined  in  preliminary  preparations. 

(5)  Task  Description  (Columns  5-25).  Enter  description  of  task; 
e.g.,  BRDG  FLTG  MAB  CL60,  or  RAFT  M4T6  CL50. 

(6)  Basic  Task  Size  (Columns  26-29).  Enter  size  of  a  basic  unit 
of  measure  for  each  engineer  task  type  such  that  any  engineer  task  may  be 
described  in  multiples  of  the  basic  unit  of  measure.  As  an  example,  if  the 
unit  length  of  one  bay  of  a  mobile  assault  bridge  is  8  meters,  enter  "8”, 
indicating  that  the  length  of  any  mobile  assault  bridge  may  be  described  in 
multiples  of  the  basic  task  size.  Selection  of  basic  task  size  should  be 
based  upon  careful  consideration  of  equipment  sizes,  employment  practices, 
the  probable  maximum  size  task  that  will  be  encountered,  and  the  number  of 
size  Increments  desired  between  minimum  (basic)  size  and  a  maximum  size. 
Intermediate  sizes  will  be  integral  multiples  of  the  basic  size.  If  equip¬ 
ment  dimensions  do  not  govern,  use  rounded  increments  such  as  tens  or 
hundreds  when  appropriate.  For  minefields,  note  that  only  barrier  minefields 
are  considered;  local  defensive  minefields  are  excluded.  If  the  basic  unit 
length  of  minefield  selected  is  100  meters,  enter  100.  The  measurement  unit 
may  be  different  for  each  task,  but  must  be  consistent  with  task  rate  units 
specified  in  subparagraph  (8)  below. 

(7)  Number  of  Sizes  (Columns  30-31).  Enter  the  number  of  sizes 
which,  when  multiplied  by  the  basic  size,  will  provide  the  maximum  magnitude 
required  for  the  task;  e.g.,  if  the  basic  size  is  100  and  the  maximum  required 
is  1200,  enter  12.  Gamers  may  assign  any  number  from  1  through  60  (see 
restriction  in  columns  32-33). 
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(8)  Number  of  Densities  (Columns  32-33).  This  field  is  intended  to 
handle  the  second  dimension  of  task  size  for  tasks  which  require  a  second 
variable  dimension  to  describe  adequately  the  task  magnitude.  For  minefield 
tasks,  enter  the  number  of  different  mine  densities  required;  e.g. ,  if  six 
different  densities  of  mines  are  to  be  playable,  enter  6.  Gamers  may  assign 
any  number  from  1  through  60,  but  the  product  of  the  numbers  in  the  basic 
task  size  (columns  26-29)  and  number  of  sizes  (columns  30-31)  must  equal  60. 

For  task  types  not  requiring  variable  densities  or  a  variable  second  dimension 
of  size,  enter  1;  otherwise,  enter  the  appropriate  number. 

(9)  Constricted  Movement  Rate  (Columns  36-42).  For  facilities  which 
tend  to  act  as  defiles  and  constrict  movement;  i.e.,  fords,  bridges,  rafts/ 
ferries,  and  lanes  through  breached  minefields,  enter  the  capacity  of  the 
facility  in  vehicles  per  hour. 

b.  Task  Performance  Rates  (Card  ID  1702).  The  Task  Performance  Rates 
card  series  provides  a  basis  for  modifying  task  rate  performance  as  affected 
by  the  quantity  of  equipment  on  site,  the  quantity  of  troops  on  site,  and  the 
site  environment.  The  card  also  provides  rate  and  loss  factors  for  vehicles 
attempting  to  force  passage  through  minefields.  Four  card  types  are  prepared 
pregame,  and  the  rate  and  loss  data  therein  remain  fixed  throughout  the  game. 

All  numbers  entered  in  the  cards  are  to  be  right  justified. 

(1)  Task  Performance  Rates  (Card  ID  1702,  Card  Type  1).  This  card 
type,  illustrated  in  Figure  IV-14-A-6,  identifies  all  equipment  items  and  supply 
items  required  for  each  type  of  engineer  function  for  each  type  of  engineer 
task,  and  provides  a  means  of  adjusting  task  rate  performance  when  the  equip¬ 
ment  and  supplies  on  site  are  less  than  the  standard  quantity  required. 

(a)  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  1 
is  printed  in  column  1  to  indicate  card  type.  In  column  2  enter  "R"  for  Red 
force  or  "B"  for  Blue  force. 

(b)  Task  Type  Number  (Columns  3-4).  Enter  task  type  number 
(see  subparagraph  (4)  above,  Card  ID  1701,  for  explanation).  Repeat  the  task 
type  number  as  many  times  as  necessary  to  cover  the  entire  spread  of  entries 
in  function  (columns  5-12)  and  item  code  (columns  13-15)  applicable  to  this 
task  type.  Then  enter  the  next  task  type  number  and  repeat  it  in  a  similar 
manner.  Continue  until  all  task  type  numbers  have  been  entered.  If  neither 
equipment  nor  supplies  is  required  for  a  task  function,  that  function  is 
omitted  from  the  listing  for  that  particular  task  type. 

(c)  Function  (Columns  5-12).  If  the  build  function  is  applicable 
to  this  task  type,  enter  BUILD  and  repeat  it  as  many  times  as  necessary  to 
cover  the  entire  spread  of  entries  in  item  code  (Columns  13-15)  applicable 

to  the  build  function  for  this  task  type.  Repeat  BUILD  once  more  to  serve  as 
a  terminal  card  for  the  build  function.  (Terminal  cards  do  not  have  any 
other  entries  except  a  card  ID  and  a  card  sequence  number).  If  the  breach 
function  is  applicable  to  this  task  type,  enter  BREACH  and  repeat  it  in  the 
same  manner  as  the  build  function,  ending  with  an  entry  for  a  terminal  breach 
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card.  If  the  remove  function  is  applicable  to  this  task  type,  enter  BREACH 
and  repeat  it  in  the  same  manner  as  the  build  function,  ending  with  an  entry 
for  a  terminal  remove  card. 

(d)  Item  Code  (Columns  13-15).  Enter  assigned  item  code  for 
each  type  of  equipment  and  each  type  of  supply  required  for  the  type  task 

and  type  function  under  consideration  (exclude  supply  classes  I,  III,  and  IIIA) . 

(e)  Minimum  Amount  (Columns  16-20).  Enter  minimum  amount 
(quantity)  of  each  type  of  equipment  and  each  type  of  supply  required  for 
threshold  performance  of  this  type  task  and  this  type  function  (exclude 
supply  classes  I,  III,  and  IIIA).  When  an  item  is  in  short  supply,  the  model 
uses  this  quantity  as  a  final  decision  point  in  determining  the  equipment 
feasibility  of  starting  a  task.  If  the  quantity  of  any  item  of  equipment 

or  supply  is  less  than  the  minimum  amount  herein  specified,  the  model  will  not 
start  the  task. 

(f)  Standard  Amount  (Columns  21-25).  Enter  standard  amount 
(quantity)  of  each  type  of  equipment  and  each  type  of  supply  normally  asso¬ 
ciated  with  this  type  task  and  this  type  function  under  average  conditions 
(exclude  supply  classes  I,  III,  and  IIIA).  The  model  uses  this  quantity  as 
a  first  decision  point  in  determining  the  equipment  feasibility  of  starting 

a  task.  If  the  quantity  available  equals  or  exceeds  this  number,  the  task  is 
feasible  from  the  standpoint  of  this  item,  and  the  model  allocates  the 
standard  amount  of  this  item  to  the  task.  If  the  quantity  available  is  less 
than  this  number,  the  model  checks  for  the  minimum  quantity  as  indicated  in 
columns  16-20 . 

(g)  Proportionality  Factor  (Columns  26-28).  The  purpose  of  this 
entry  is  to  provide  a  proportionality  factor  which  will  serve  to  scale  the 
quantity  of  an  equipment  or  supply  item  to  fit  any  engineer  task  size.  Two 
proportionality  value  ranges  are  used  to  store  data  in  this  field:  0-120 
for  expendable  and  121-250  for  nonexpendable  suDplies,  and  equipment.  If 
the  amount  of  supplies  and  equipment  to  execute  an  engineer  task  type  is 
constant,  independent  of  task  size  and  density,  and  expendable,  set  PFe 
equal  to  0;  where  PFe  is  the  proportionality  factor  for  expendable  supplies 

and  equipment.  If  the  amount  of  equipment  and  supplies  is  constant,  independent 
of  task  size  and  density,  and  nonexpendable,  set  PFn  equal  to  250;  where  PFn 
is  the  proportionality  factor  for  nonexpendable  supplies  and  equipment.  If 
the  supplies  and  equipment  to  execute  an  engineer  task  are  not  constant,  select 
a  value  of  i  such  that  AMTi  ^  2AMTi,  where: 

AMTj_  *  standard  amount  of  supplies  and  equipment 
to  execute  engineer  basic  task  size. 

(AMT^  is  derived  from  engineer  field 
manuals  or  military  engineer  judgment 
and  is  identical  to  standard  amount  in 
columns  21-25) . 

AMT^  ■  standard  amount  of  supplies  and  equipment 
to  execute  the  desired  engineer  task 
type  and  size  i. 


IV-14-A-16 


Calculate: 


AHTi 

AiMT1  -  AMT]_ 


(IV-14-A-1) 


X 


i 


Calculate: 


PF  -  10  (i-2)  +  10  X. 

e  X 


(IV-14-A-2) 


If  the  equipment  item  is  expendable,  enter  calculated  PFe  in  columns  26-28; 
if  equipment  is  nonexpendable,  calculate 

PFn  =  PFe  +  120  (IV-14-A-3) 

and  enter  PFn  in  columns  26-28. 

For  minefields,  AMT^  and  AMT^  will  vary  by  task  size  and  density. 

(h)  Transport  Item  Code  (Columns  29-31).  Enter  item  code  of  the 
vehicle  type  that  will  normally  transport  this  type  accountable  equipment  during 
a  move.  If  this  equipment  is  self-propelled  and  normally  transports  itself 
independently,  enter  the  same  item  code  as  in  columns  13-15. 

(i)  Equipment  Rate  Modifiers  (Columns  33-72).  The  purpose  of  this 
field  is  to  provide  a  basis  for  modifying  the  rate  of  task  performance  when 
the  quantity  of  this  equipment  type  varies  and  the  size  of  the  task  varies. 
Provision  is  made  for  five  levels  for  each  equipment  type,  with  eight  columns 
for  each  level,  the  first  five  columns  of  which  are  used  for  the  quantity  of 
equipment  and  the  last  three  columns  for  the  rate  modifier.  Columns  33-40 

are  for  level  1;  columns  41-48,  for  level  2;  columns  49-56,  for  level  3; 
columns  57-64,  for  level  4;  and  columns  65-72,  for  level  5.  The  user  specifies 
as  many  of  the  five  levels  as  desired.  Enter  equipment  quantities  and  rate 
modifiers  in  appropriate  columns  in  accordance  with  the  following  quidance: 

.  At  least  one  level  must  be  specified. 

.  If  fewer  than  five  levels  are  used,  they  must  be 
right  justified. 

.  Quantities  will  be  in  ascending  order  from  left 
to  right. 

.  The  left-most  quantity  will  be  interpreted  to  be 
the  minimum  required  for  the  task;  hence,  the 
entry  must  be  identical  to  the  quantity  indicated 
in  the  related  columns  16-20. 
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Intervals  between  levels  may  be  variable. 


.  Rate . modifiers  will  be  used  as  multiplying  factors 
and  must  be  specified  in  terms  of  100  for  the 
standard. 

(2)  Task  Performance  Rates  (Card  ID  1702,  Card  Type  2).  This  card 
type,  illustrated  in  Figure  IV-14-A-7,  identifies  the  quantity  of  troops 
required  for  each  type  of  engineer  function  for  each  type  of  engineer  task, 
and  provides  a  means  of  adjusting  task  rate  performance  when  the  troops  on 
site  are  less  than  the  standard  quantity  required. 

(a)  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  2 
is  printed  in  column  1  to  indicate  Card  Type  2.  In  column  2  enter  "R"  for 
Red  force  or  "B"  for  Blue  force. 

(b)  Task  Type  Number  (Columns  3-4).  Enter  task  type  number 
(see  subparagraph  a(4)  above,  Card  ID  1701,  for  explanation).  Repeat  the 
task  type  number  as  many  times  as  necessary  to  cover  the  entire  spread  of 
entries  in  the  next  three  fields  applicable  to  this  task  tvoe.  Then  enter  the 
next  task  type  number  and  repeat  it  in  a  similar  manner.  Continue  until  all 
task  type  numbers  have  been  entered. 

(c)  Function  (Columns  5-12).  If  the  build  function  is  applicable 
to  this  task  type,  enter  BUILD  and  repeat  it  as  many  times  as  necessary  to 
cover  the  entire  spread  of  entries  in  the  next  two  fields  applicable  to  the 
build  function  for  this  task  type.  (For  this  card  type  no  terminal  cards  are 
used  for  the  function.)  If  the  breach  function  is  applicable  to  this  task 
type,  enter  BREACH  and  repeat  it  in  the  same  manner  as  the  build  function.  If 
the  remove  function  is  applicable  to  this  task  type,  enter  REMOVE  and  repeat 
it  in  the  same  manner  as  the  build  function. 

(d)  Size  Number  (Columns  13-14)  and  Density  Number  (Columns 
15-16).  These  two  fields  present  all  combinations  of  the  task  size  numbers 
and  density  numbers  shown  in  card  ID  1701  as  an  index  to  the  matrix  of  task 
performance  rate  values  provided  by  the  next  two  fields  of  this  card.  These 
entries  are  made  as  follows.  In  column  14  enter  the  task  size  number  1 
(smallest  task  size),  and  in  the  same  row  in  column  16  enter  density  number  1. 
Keep  repeating  task  size  number  1  in  column  14  until  all  density  numbers  have 
been  entered  opposite  it  once  in  columns  15-16.  Then  enter  task  size  number 

2  and  start  once  again  with  density  number  1,  repeating  task  size  number  2 
until  all  density  numbers  have  been  entered  opposite  it  once  in  columns  15-16. 
Continue  with  task  size  number  3,  number  4,  etc.,  until  all  task  size  numbers 
have  been  used.  Illustration  a  below  shows  a  sample  with  four  task  size 
numbers  and  three  density  numbers.  If  the  number  of  density  numbers  is  one, 
then  enter  each  task  size  number  only  once  in  columns  13-14,  and  enter  density 
number  1  once  in  column  16  opposite  each  entry  in  columns  13-14,  as  shown  in 
Illustration  b  below. 
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Columns  13-14 


Columns  13-14  Columns  15-16 


1 

1 

1 

2 

2 

2 

3 

3 

3 

4 
4 
4 


1 

2 

3 

1 

2 

3 

1 

2 

3 

1 

2 

3 


1  1 

2  1 

3  1 

4  1 

5  1 

6  1 

7  1 

8  1 

9  1 

10  1 

11  1 

etc .  1 


Illustration  a 


Illustration  b 


(e)  Minimum  Troop  Level  (Columns  18-27).  This  data  entry  provides 
a  lower  bound  on  the  feasibility  of  starting  a  task,  to  provide  a  basis  for 
allocation  of  troops  to  tasks  when  resources  on  hand  are  inadequate  to 
allocate  the  standard  quantity,  and  to  relate  these  quantities  to  task  per¬ 
formance  rates.  Two  types  of  entry  are  required;  the  first  for  the  minimum 
quantity  of  troop  units  required,  and  the  second  for  the  rate  of  task  per¬ 
formance. 


J..  Number  of  Units  (Columns  18-19) .  Enter  the  minimum 
number  of  engineer  platoons  required.  One  special  case  needs  separate 
consideration;  this  case  involves  tasks  requiring  more  than  one  type  of 
engineer  platoon;  e.g.,  bridge  platoons  and  combat  platoons.  In  this  case, 
enter  the  minimum  number  of  platoons  of  the  type  other  than  the  combat 
platoons;  the  model  computes  the  corresponding  number  of  combat  platoons. 

2_.  Rate  (Columns  20-27).  Enter  the  corresponding  rate  of 
task  performance  using  the  indicated  number  of  troop  units.  An  implied 
decimal  point  is  located  between  columns  24  and  25.  The  units  for  this  rate 
will  vary  by  task  type;  units  to  be  used  for  these  task  rate  data  are  shown 
in  Figure  IV-14-A-8. 

(f)  Standard  Troop  Level  (Columns  29-38).  This  data  entry 
provides  a  basis  for  allocation  of  troops  to  tasks  when  resources  on  hand 
are  adequate  to  allocate  the  standard  quantity,  and  relates  these  quantities 
to  task  performance  rates.  If  the  quantity  available  is  less  than  this  num¬ 
ber,  the  model  checks  for  the  minimum  quantity  as  indicated  in  the  previous 
field.  Two  types  of  entry  are  required;  the  first  for  the  standard  quantity 
of  troop  units  required,  and  the  second  for  the  rate  of  task  performance. 
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Common  Name 


Task  Type 
Blue 
Type 


Red 

Type 


Function 


Rate  Unit  To  Be  Used 


a.  Based  on  standard  lane  width  of  8  meters  for  single  flow  vehicle  lane,  standard  minefield 
depth  of  300  meters. 


b.  Based  on  standard  lane  width  of  8  meters  for  single  flow  vehicle  lane  and  a  double  row  of 
cratering  charges,  three  charges  per  row,  and  charge  depth  of  3  meters. 

c.  Based  on  placement  of  charges  to  cut  full  width  of  decking  In  two  places  and  to  rupture 
each  ponton  of  section  isolated  for  destruction  (at  least  four  pontons). 

d.  Based  on  time  required  for  equipment  operators  to  disengage  two  interbay  connections  and 
to  remove  resulting  multibay  raft  (at  least  two  bays). 

e.  Based  on  2  minutes  to  emplace  a  bridge,  giving  a  rate  of  0.111  minute  per  meter  for  an 
18-meter  AVLB  and  0.100  minute  per  meter  for  a  20-meter  M-1967.  Task  size  is  taken  as  constant 
at  18  meters  for  AVLB  and  20  meters  for  M-1967. 

f.  Based  on  placement  of  two  satchel  charges,  one  over  each  main  girder. 

g.  Removal  time  taken  equal  to  emplacement  time,  hence  rates  same  as  note  e  above. 

h.  Based  on  placement  of  a  minimum  of  six  major  charges  per  lane  width. 


Figure  IV-14-A-8.  Engineer  Task  Rate  Units 


IV-14-A-21 


1_.  Number  of  Units  (Columns  29-30).  Enter  the  standard 
number  of  engineer  platoons  required.  The  special  case  is  the  same  as  that 
for  the  previous  field,  substituting  the  word  "standard"  for  the  word 
"minimum"  wherever  the  latter  occurs  therein. 

2.  Rate  (Columns  31-38).  Enter  the  corresponding  rate  of 
task  performance  using  the  indicated  number  of  troop  units.  The  units  for 
these  rates  are  the  same  as  those  fc .•  columns  20-27.  An  implied  decimal 
point  is  located  between  columns  35  and  36. 

(3)  Task  Performance  Rates  (Card  ID  1702,  Card  Type  3).  This  card 
type,  illustrated  in  Figure  IV-14-A-9,  provides  a  means  of  adjusting  task  rate 
performance  to  reflect  the  influence  of  the  environmental  conditions  of  the 
task  site  and  the  influence  of  reduced  visibility  at  night.  If  no  data  of 
this  type  are  entered,  all  functions  are  accomplished  using  the  basic  rates 
provided  on  card  ID  1702  type  2. 

(a)  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  3 
is  printed  in  column  1  to  indicate  card  type  3.  In  column  2  enter  "R"  for 
Red  force  or  "B"  for  Blue  force. 

(b)  Task  Type  Number  (Columns  3-4).  Enter  task  type  number 
(see  subparagraph  a(2)  above.  Card  ID  1701,  for  explanation.  Repeat  the 
task  type  number  as  many  times  as  necessary  to  cover  the  spread  of  entries  in 
the  next  field  applicable  to  this  task  type.  Then  enter  the  next  task  type 
number  and  repeat  it  in  a  similar  manner.  Continue  until  all  task  type 
numbers  have  been  entered. 

(c)  Function  (Columns  5-12).  Every  function  applicable  to  this 
task  type  will  have  its  separate  entry.  If  the  build  function  is  applicable 
to  this  task  type,  enter  BUILD.  If  the  breach  function  is  applicable,  enter 
BREACH.  If  the  remove  function  is  applicable,  enter  REMOVE. 

(d)  Rate  Modifiers  (Columns  14-32).  This  data  entry  provides 
rate  modifiers  to  reflect  degradation  in  task  rate  performance  due  to 
environmental  conditions.  Six  types  of  entry  are  required. 

1.  Night  (Columns  14-16).  This  entry  covers  degradation  due 
to  night  conditions.  Based  on  a  visibility  value  of  100  for  average  daylight 
conditions,  enter  a  value  less  than  100  to  represent  the  average  proportional 
visibility  value  for  night  conditions.  The  model  recognizes  night  conditions 
from  the  end  of  evening  nautical  twilight  (EENT)  to  the  beginning  of  morning 
nautical  twilight  (BMNT). 

2.  Terrain  (Columns  18-32).  The  other  five  entries  cover 
degradation  due  to  terrain  trafficability  factors.  Based  on  a  rate  modifier 
of  100  for  bare,  smooth,  flat  terrain,  enter  in  each  of  these  fields  a  value 
equal  to  or  less  than  100  to  represent  the  average  proportional  rate  modifier 
for  engineer  task  sites.  The  terrain  designators  correspond  to  trafficability 
indexes  defined  in  Chapter  4  as  follows: 
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Terrain 

Designator 


Traf ficabilitv 
Index 


A 

B 

C 

D 

E 


01-04 

05-08 

09-12 

13-16 

17-20 


All  terrain  rate  modifiers  can  be  identical  for  a  type  task;  and,  if  the 
battle  area  is  homogeneous,  can  be  uniform  for  all  task  types. 

(4)  Task  Performance  Rates  (Card  ID  1702,  Card  Type  4).  This  card 
type,  illustrated  in  Figure  IV-14-A-10,  provides  rates  for  vehicles  when 
forcing  passage  of  minefields  and  provides  means  of  assessing  vehicle  losses. 

(a)  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  4 
is  printed  in  column  1  to  indicate  card  type  4.  In  column  2  enter  "R"  for 
Red  force  or  "B"  for  Blua  force. 

(b)  Task  Type  Number  (Columns  3-4).  Enter  task  type  number. 

See  subparagraph  a(4) ,  Card  ID  1701,  for  explanation.  Task  type  number  is 
restricted  to  tasks  involving  minefields;  i.e. ,  types  1,  2,  and  3.  Repeat 
the  task  type  number  as  many  times  as  necessary  to  cover  the  spread  of  entries 
in  the  size  and  density  fields  (columns  13-16)  applicable  to  this  task  type. 
Then  enter  the  next  task  type  number  and  repeat  it  in  a  similar  manner. 
Continue  this  until  all  pertinent  task  type  numbers  have  been  entered. 

(c)  Function  (Columns  5-12).  Enter  task  function,  FORCE. 

(d)  Size  Number  (Columns  13-14)  and  Density  Number  (Columns  15- 
16).  These  two  fields  present  all  combinations  of  the  task  size  numbers  and 
density  numbers  shown  in  card  ID  1701  as  an  index  to  the  matrix  of  crossing 
rates  and  equipment  losses  provided  by  the  next  two  fields  of  this  card. 
Preparation  of  these  entries  is  analogous  to  that  for  card  type  2. 

(e)  Forcing  Rate  (Columns  17-23).  Enter  permissible  vehicle 
velocity  (meters  per  minute)  while  forcing  a  crossing  of  minefields. 

(f)  Forcing  Losses  (Columns  26-50).  This  field  provides  a 
matrix  of  types  of  vehicles  which  may  force  minefields  and  the  related 
assessed  losses  of  such  vehicles  while  so  forcing.  Only  tracked-type  combat 
vehicles  are  permitted  to  effect  the  forcing  breach.  Five  identical  type 
entries  are  required,  each  of  which  is  divided  into  two  areas:  the  first 
area  (three  columns)  is  for  the  assigned  item  code  for  a  vehicle  type 
permitted  to  force  minefields,  and  the  related  second  area  (two  columns)  is 
for  the  assessed  quantity  of  that  type  of  vehicle  lost  while  forcing  such 
minefields.  Enter  in  the  first  area  the  item  code  and  in  the  second  area  the 
related  amount  of  that  type  vehicle  lost.  The  bases  for  loss  assessment  are 
density  of  mines  and  ground  contact  width  of  tracks. 
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Task  Performance  Rates  for  Vehicles  Crossing  Minefie 
Card  Format 


c.  Contingency  Levels  (Card  ID  1703).  This  card  series  provides  a  means 
to  hold  some  engineer  resources  in  reserve  for  conditional  or  contingency 
tasks  so  that  the  model  does  not  commit  all  of  the  resources  simultaneously 
and  thereby  leave  the  force  devoid  of  resources  pending  completion  of  tasks. 

It  also  provides  a  means  for  controlling  critical  items.  Two  card  types  are 
prepared  pregame.  The  contingency  data  generally  remain  fixed  throughout  the 
game  but  may  be  altered  between  game  periods  if  desired.  All  numbers  entered 
in  the  cards  are  to  be  right  justified. 

(1)  Contingency  Levels  (Card  ID  1703,  Card  Type  1).  This  card  type, 
illustrated  in  Figure  IV-14-A-11,  provides  a  means  for  the  gamer  to  specify 
contingency  levels  for  equipment  he  desired  to  hold  in  reserve  for  mandatory 
tasks  which  are  scheduled  or  may  arise;  e.g.,  tasks  resulting  from  Movement 
Model  operation,  or  conditional  DSL  orders.  The  model  cannot  allocate  contin¬ 
gency  equipment  to  desired  tasks  but  can  allocate  then  to  mandatory  tasks. 

(a)  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  1 
is  printed  in  column  1  to  indicate  card  type  1.  In  column  2  enter  "R"  for 
Red  force  or  "B"  for  Blue  force. 

(b)  Contingency  Levels  -  Equipment  (Columns  3-66).  This  field 
provides  a  means  for  listing  the  equipment  to  be  withheld  for  contingencies. 
Eight  identical  subfields  are  provided,  each  of  which  is  divided  into  two 
areas:  the  first  area  (four  columns)  is  for  the  assigned  item  code  for  an 
equipment  type,  and  the  related  second  area  (four  columns)  is  for  the  amount 
of  that  equipment  type  to  be  held  in  contingency  reserve.  Enter  in  the  first 
area  the  item  code  and  in  the  second  area  the  amount.  If  no  entries  are 
made,  the  model  interprets  all  contingency  levels  at  zero. 

(2)  Contingency  Levels  (Card  ID  1703,  Card  Tvoe  2).  This  card  type, 
illustrated  in  Figure  IV-14-A-12,  provides  a  means  to  specify  contingency 
levels  for  troop  units  which  he  desires  to  hold  in  reserve  for  mandatory 
tasks.  The  model  cannot  allocate  contingency  units  to  desired  tasks  but  can 
allocate  then  to  mandatory  tasks. 

(a)  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  2 
is  printed  in  column  1  to  indicate  card  type  2.  In  column  2  enter  "R"  for 
Red  force  or  "B"  for  Blue  force. 

(b)  Contingency  Levels  -  Troop  Units  (Columns  3-43).  This  field 
provides  a  means  for  listing  the  troop  units  to  be  withheld  for  contingencies. 
Six  identical  subfields  are  provided,  each  of  which  is  divided  into  two  areas: 
the  first  area  (four  columns)  is  for  the  type  of  troop  unit,  and  the  related 
second  area  (two  columns)  is  for  the  number  of  such  units  to  be  held  in  con¬ 
tingency  reserve.  Enter  in  the  first  area  the  code  for  the  unit  type  and  in 
the  second  area  the  amount.  If  no  entries  are  made,  the  model  interprets 

all  contingency  levels  at  zero.  Codes  to  be  used  for  unit  types  are  specified 
in  Figure  IV-14-A-13  in  terms  of  Blue  unit  types;  these  same  codes  will  be 
used  for  equivalent  Red  unit  types: 
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i-12.  Contingency  Levels  for  Troops  Card  Format 


Unit 

Code 

Type  Unit 

1 

MNVR 

Maneuver  unit  (company) 

2 

ENGR 

Combat  engineer  unit  (platoon) 

3 

ADM 

Atomic  demolition  munition  unit 
(platoon) 

4 

MAB 

Floating  bridge  unit  (heavy  raft, 
platoon,  MAB) 

5 

FLBR 

Floating  bridge  unit  (bridge 
platoon,  M4T6) 

6 

Open 

Figure  IV-14-A-13.  Unit  Tyne  Codes 


4.  ENGINEER  CONSTANT  DATA  DECK  STRUCTURE.  Two  different  data  deck  structures 
are  required,  one  for  the  barrier  and  facility  file  and  one  for  the  engineer 
task  data  base;  each  deck  has  a  separate  load  program. 

a.  Engineer  Constant  Data  Input  Cards.  Ten  types  of  cards  are  used,  as 
indicated  in  Figure  IV-14-A-14.  The  first  three  types  pertain  to  the  barrier 
and  facility  file  and  the  remaining  seven  types  to  the  engineer  task  data  base. 

b.  Creating  Barrier  and  Facility  File.  The  barrier  and  facility  file 

is  created  by  reading  in  the  data  deck  structured  as  shown  in  Figure  IV-14-A-15. 
In  this  figure  are  a  series  of  subdecks,  each  of  which  pertain  to  a  specific 
barrier  line.  The  first  block  of  these  subdecks  covers  Blue  force  barriers, 
and  the  second  block  covers  Red  force  barriers.  Each  subdeck  is  headed  by 
a  barrier  line  identification  card,  ID  0201,  type  1,  and  is  followed  by  a 
barrier  line  end  card  which  carries  only  the  initial  identifier  IB  or  1R  in 
columns  1  and  2,  the  minus  one  (-1)  designator  in  columns  16  and  17,  and  the 
card  ID  number  0202  in  columns  73-76.  Within  the  barrier  segment  details 
subdeck,  the  cards  are  arranged  from  front  to  rear,  in  the  consecutive  order 
of  the  barrier  segments,  starting  from  one  end  of  the  barrier  line  and 
progressing  to  the  other  end. 


c.  Creating  Engineer  Task  Constant  Data  File.  The  engineer  task  constant 
data  file  is  created  by  reading  in  the  data  deck  structured  as  shown  in  Figure 
IV-14-A-16.  In  this  figure  are  a  series  of  subdecks,  each  of  which  contains 
specific  types  of  data  and  is  preceded  by  a  header  card.  There  are  two  identical 
blocks  of  these  subdecks,  the  first  one  containing  engineer  tasks  for  Blue  forces 
and  the  second  one  for  Red  forces.  Within  the  subdecks,  individual  cards  are 
arranged  from  front  to  rear  as  follows: 


Card  Title 

Card 

ID 

Load 

Program  Name 

Barrier  System  Location 

0200 

BARLOAD 

Barrier  Line  Identification 

0201 

BARLOAD 

Barrier  Segment  Details 

0202 

BARLOAD 

Task  Identification 

1701 

ENGLD 

Task  Performance  Rates  (Equipment) 

1702 

ENGLD 

Task  Performance  Rates  (Troops) 

1702 

ENGLD 

Task  Performance  Rates  (Environment) 

1702 

ENGLD 

Task  Performance  Rates  (Forcing) 

1702 

ENGLD 

Contingency  Levels  (Equipment) 

1703 

ENGLD 

Contingency  Levels  (Troops) 

1703 

ENGLD 

Figure  IV-14-A-14.  Engineer  Constant  Data  Card  Types 
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Figure  IV-14-A-15. 


Barrier  and  Facility  Data  Deck  Structure 
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Figure  IV-14-A-16.  Engineer  Task  Data  Deck  Structure 


(1)  Task  Identification  Subdeck.  Arrange  cards  in  numerical  order 
on  task  type  numbers;  some  numbers  may  not  be  in  use,  e.g.: 

Task  type  1 
Task  type  2 


Task  type  25 


(2)  Task  Performance  Rates  (Equipment)  Subdeck.  Arrange  cards  so 
that  task  type  numbers  are  in  numerical  order,  and  all  cards  within  a  task 
type  number  and  with  like  function  are  grouped  together  in  each  function  order, 
build,  breach,  and  remove.  Function  end  cards  are  prepared  with  all  initial 
entries  through  function  (columns  1  through  15)  with  nothing  else  except  the 
card  ID  1702  in  columns  73-76;  e.g: 


Task  type  1 
Task  type  1 
Task  type  1 
Task  type  1 
Task  type  1 
Task  type  1 
Task  type  1 
Task  type  1 
Task  type  1 
Task  type  2 
Task  type  2 
Task  type  2 
Task  type  2 


Function  BUILD 
Function  BUILD 
Function  BUILD 
Function  BUILD 
Function  BREACH 
Function  BREACH 
Function  BREACH 
Function  REMOVE 
Function  REMOVE 
Function  BUILD 
Function  BUILD 
Function  BUILD 
Function  BREACH 


Item  Code  XXX 
Item  Code  YYY 
Item  Code  ZZZ 
(End  Card) 
Item  Code  RRR 
Item  Code  SSS 
(End  Card) 
Item  Code  XYZ 
(End  Card) 
Item  Code  YYY 
Item  Code  XXX 
(End  Card) 
Item  Code  SSS 


(3)  Task  Performance  Rates  (Troops)  Subdeck.  Arrange  cards  so  that 
task  type  numbers  are  in  numerical  order  and  all  cards  within  a  task  type 
number  and  with  like  function  are  grouped  together  in  each  function  order, 
build,  breach,  and  remove.  Within  a  function,  size  numbers  are  in  numerical 
order,  and  cards  with  the  same  size  number  are  grouped  together,  with 
densities  in  numerical  order;  e.g: 


Task 

type 

1 

Function 

BUILD 

Size 

1 

Density 

Task 

type 

1 

Function 

BUILD 

Size 

1 

Density 

Task 

type 

1 

Function 

BUILD 

Size 

1 

Density 

Task 

type 

1 

Function 

BUILD 

Size 

2 

Density 

Task 

type 

1 

Function 

BUILD 

Size 

2 

Density 

Task 

type 

1 

Function 

BUILD 

Size 

2 

Density 

Task 

type 

1 

Function 

BREACH 

Size 

1 

Density 

Task 

type 

1 

Function 

BREACH 

Size 

1 

Density 

Task 

type 

1 

Function 

BREACH 

Size 

1 

Density 
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Task 

type 

1 

Function 

BREACH 

Size 

2 

Density 

1 

Task 

type 

1 

Function 

BREACH 

Size 

2 

Density 

2 

Task 

type 

1 

Function 

BREACH 

Size 

2 

Density 

3 

Task 

type 

1 

Function 

REMOVE 

Size 

1 

Density 

1 

Task 

type 

1 

Function 

REMOVE 

Size 

1 

Density 

2 

Task 

type 

1 

Function 

REMOVE 

Size 

1 

Density 

3 

Task 

type 

1 

Function 

REMOVE 

Size 

2 

Density 

1 

Task 

type 

1 

Function 

REMOVE 

Size 

2 

Density 

2 

Task 

type 

1 

Function 

REMOVE 

Size 

2 

Density 

3 

Task 

type 

2 

Function 

BUILD 

Size 

1 

Density 

1 

Task 

type 

2 

Function 

BUILD 

Size 

1 

Density 

2 

(4)  Task  Performance  Rates  (Environment)  Subdeck.  Arrange  cards 
so  that  task  type  numbers  are  in  numerical  order  and  functions  in  order, 
build,  breach,  and  remove: 


Task  type  1 
Task  type  1 
Task  type  1 
Task  type  2 
Task  type  2 
Task  type  2 
Task  type  3 


Function  BUILD 
Function  BREACH 
Function  REMOVE 
Function  BUILD 
Function  BREACH 
Function  REMOVE 
Function  BUILD 


(5)  Task  Performance  Rates  (Forcing)  Subdeck.  Arrange  cards  so 
that  task  type  numbers  are  in  numerical  order,  and  within  a  task  type  number, 
size  numbers  are  in  numerical  order  and  cards  with  the  same  size  number  are 
grouped  together,  with  densities  in  numerical  order: 


Task 

type 

1 

Function 

FORCE 

Size 

1 

Density 

1 

Task 

type 

1 

Function 

FORCE 

Size 

1 

Density 

2 

Task 

type 

1 

Function 

FORCE 

Size 

1 

Density 

3 

Task 

type 

1 

Function 

FORCE 

Size 

2 

Density 

1 

Task 

type 

1 

Function 

FORCE 

Size 

2 

Density 

2 

Task 

type 

1 

Function 

FORCE 

Size 

2 

Density 

3 

Task 

type 

2 

Function 

FORCE 

Size 

1 

Density 

1 

Task 

type 

2 

Function 

FORCE 

Size 

1 

Density 

2 

Task 

type 

2 

Function 

FORCE 

Size 

1 

Density 

3 

Task 

type 

2 

Function 

FORCE 

Size 

2 

Density 

1 

(6)  Contingency  Levels  (Equipment)  Subdeck.  No  special  arrangement 
of  cards  is  required  in  this  subdeck;  however,  if  any  card  has  fewer  than  eight 
equipment  columns  filled,  that  card  Is  placed  last  in  the  deck.  If  no  equip¬ 
ment  contingency  levels  are  specified,  such  levels  default  to  zero;  in  such 
cases,  both  this  deck  and  its  header  card  are  omitted. 


(7)  Contingency  Levels  (Troops)  Subdeck.  This  deck  consists  of  a 
single  card.  If  no  troop  contingency  levels  are  specified,  such  levels  default 
to  zero;  in  such  cases,  both  this  card  and  its  header  card  are  omitted. 


» 
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APPENDIX  B 


ENGINEER  MODEL  PROGRAM  DESCRIPTIONS 


1.  INTRODUCTION.  Routines  accomplishing  the  engineer  functions  modeled  in 
DIVWAG  are  included  in  overlay  12.  Overlay  segmentation  is  for  running 
efficiency  and  is  not  generally  related  to  logical  sequence  of  the  model.  The 
macro  flow  of  the  Engineer  Model  is  shown  in  Figures  IV-14-2  through  IV-14-8. 

a.  Routines.  The  controlling  routine  of  overlay  12  is  ENGR,  which  serves 
as  the  interface  with  the  system.  Major  routines  within  the  overlay  are 
EPRIOR,  PRORTY,  EFASI,  FESBIL,  ERELEA,  and  EUPDAT.  Supporting  routines  within 
the  overlay  include  BUIDRC,  CREA16 ,  EQPT,  EQPTUP,  GEOM,  IRECN1,  MPRACL, 

MPRUPD,  SG1201,  STUNIT,  SET37 ,  and  UNTORG,  CRTQD,  which  also  appears  in 
overlay  3,  is  described  in  this  appendix. 

b.  Variables.  Routines  within  overlay  12  use  a  limited  set  of  variables, 
appearing  with  the  same  variable  names  throughout  the  overlay.  These  include 
standard  common  block  areas  UMAIN,  UCOOP,  and  TCLOCK.  Additional  variables 
general  to  the  overlay  are  listed  below.  Within  the  routine  descriptions, 
variables  other  than  these  standard  engineer  overlay  data  are  specified 
where  appropriate. 

Name  Source/Destination  Contents 


I0F(35) 

DF2 

Barrier  file  record. 

PTYLST(6) 

DF18 

Priority  list,  unique  to  each  task  in 
queue . 

IARRAY(60) 

DF37 

Borrowed  equipment  file. 

JARRAY(3) 

DF16 

Three-word  array: 

W0RD1  ■  number  of  tasks  in  queue. 
W0RD2  -  flag  indicating  new  game. 
W0RD3  ■  flag  indicating  new  period. 

IDUM(94 
through  129) 

TWO 

Data  file  12  record  for  automatic 
event  sequencing. 

N0RD1 

IDUM(94) .  Engineer  NORD. 

STRSTP 

IDUM(96).  DSL  stop  task. 

BARBRI 

IDUM(97).  Bridge/barrier  flag: 

1  ■  bridge 

0  ■  barrier 

UIDB 

IDUM(98) .  Task  mnemonic. 

IBARNM 

IDUM(99) 
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Name 


Sour ce/Destinat ion 


Contents 


PRTY 

IDUM(IOO) . 

DSL  priority. 

CMPBGN 

IDUM(lOl).  Complete-by-begin-by  flag: 

1  *  begin  by;  0  =  complete  by. 

MNDPTY 

IDUM(1Q2).  Mandatory-desired  flag: 

1  »  mandatory;  0  *  desired. 

ENGRTM 

IDUM(103) . 

Time  engineer  event  begins. 

BLUFRC 

IDUM(104) . 
0  **  Red;  1 

Blue/Red  force  to  execute: 

-  Blue. 

ENGOPR 

IDUM (105).  Operation  code  to  allow 
proper  branching  in  parts  of  model. 

BARIDX 

IDUM(106).  Barrier  record  number  passed 
only  by  mobility  with  ENG0PR*3. 

IUIDRQ 

IDUM(107).  IUID  of  unit  requesting  task 
passed  only  by  mobility  with  ENGOPR**3. 

2.  ROUTINE  ENGR: 

a.  Purp>-  :e.  ENGR  is  the  controlling  routine  of  the  Engineer  Model  overlay 
that  calls  the  various  routines  in  response  to  event  codes  passed  to  it  by 
data  file  12,  the  automatic  event  file,  and  sets  up  reentry  to  the  overlay 
through  data  file  12.  The  routine  is  also  the  point  of  entry  for  all  DSL 
orders  to  the  model  and,  as  a  utility  function,  decomposes  engineer  mission 
units  upon  task  completion. 

b.  Major  Variables.  The  routine  uses  all  variables  listed  in  paragraph  lb 

c.  Logical  Flow  (Figure  IV-14-B-1): 

(1)  Block  1.  If  this  is  not  a  DSL  start-of-period  instruction, 
control  branches  to  block  L100;  otherwise, control  goes  to  block  2. 

(2)  Blocks  2,  7,  and  8.  If  this  is  not  the  first  DSL  instruction  to 
enter  the  model  and  not  the  start  of  a  new  period,  control  goes  to  block  L40; 
otherwise,  control  goes  to  block  L80. 

(3)  Blocks  L80,  4,  5,  6,  9,  and  10.  Blocks  L80,  4,  5,  6,  and  9 
generate  the  necessary  returns  to  the  Engineer  Model  throughout  the  period. 
ENGOPR  is  reset  to  its  original  value.  If  ENGOPR  is  equal  to  3,  control  goes 
to  block  L70. 

(4)  Block  L40.  The  barrier  record  number  corresponding  to  the 
mnemonic  input  through  DSL  is  calculated  by  routine  BUIDRC. 


Figure  IV-14-B-1 . 


Routine  ENGR  (Continued) 
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Figure  IV-14-B-1. 


Routine  ENGR  (Continued) 
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Figure  IV-14-B-1. 


Routine  ENGR  (Continued) 
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Figure  IV-14-B-1.  Routine  ENGR  (Continued) 
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Figure  IV-14-B-1.  Routine  ENGR  (Concluded) 
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(5)  Block  L70.  After  the  record  number  has  been  determined,  bring 
in  the  barrier  record  from  data  file  2. 

(6)  Blocks  11,  L50,  12,  and  13.  Store  task  information  on  barrier 
file  2  and  create  a  data  file  18  record  corresponding  to  the  task.  Increment 
the  number  of  tasks  in  the  queue  and  return  this  value  to  data  file  16. 

(7)  Block  14.  If  there  are  more  tasks  control  returns  to  the  calling 
routine.  If  not  and  this  is  a  conditional  task,  set  ENGOPR  equal  to  two  and 
transfer  control  to  block  LI. 

(8)  Block  LI.  If  the  task  need  not  be  terminated  due  to  the 
proximity  to  the  FEBA  or  a  DSL  stop  order,  the  task  priority,  manhours 
required  to  complete  the  task,  and  the  starting  time  are  determined  in 
routines  EPRIOR  and  PRORTY.  Priorities  are  also  ranked  according  to 
battle  significance. 

(9)  Block  15.  If  a  task  is  feasible,  manpower  and  resources  are 
allocated, and  movement  orders  are  generated  by  routine  EFEASI. 

(10)  Blocks  16,  17,  and  18.  Generate  the  next  entry  to  the  Engineer 
Model  to  update  allocated  tasks  and  to  allocate  other  tasks.  Control  returns 
to  the  calling  routine. 

(11)  Blocks  L3  and  L2.  Get  the  barrier  record  number  from  data  file  2 
and  the  current  number  of  tasks  in  the  queue.  If  this  is  a  mobility  request, 
transfer  control  to  L70;  otherwise,  transfer  control  to  L40. 

(12)  Blocks  L5,  19,  and  20.  CREA16  updates  the  engineer  geometry  each 
60  minutes,  on  the  hour.  Expenditures  fo  equipment  and  supplies  since 
previous  update  are  calculated.  Routine  EUPDAT  increases  the  number  of 
expended  manhours  and  releases  units  if  the  task  is  complete;  if  not,  the 
routine  allocates  necessary  manpower  and  supplies  for  completion.  Routine 
EFEASI  allocates  manpower  and  supplies  to  tasks  not  underway.  Control  returns 
to  the  calling  routine. 

(13)  Block  L6.  ENUCLE  finds  barriers  within  nuclear  effects  radius 
and  creates  and  updates  radiological  barriers.  Control  returns  to  the 
calling  routine. 

(14)  Block  Lll.  Bring  in  data  for  the  unit  arriving  at  the  task  site 
and  place  it  on  the  barrier  record  for  this  task. 

(15)  Block  21.  If  the  arriving  unit  is  the  mission  unit  for  this  task, 
set  beginning  task  time  equal  to  current  time. 

(16)  Block  22.  If  this  unit  was  not  the  first  unit  to  arrive  at  the 
task  site,  call  routine  EUPDAT  to  process  activity  at  the  site  since  the 
previous  update,  and  the  unit's  supplies  and  manpower  are  added  to  others 

at  the  site.  Control  is  returned  to  the  calling  routine. 
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(17)  Block  L12.  When  a  unit  returns  to  the  parent  unit  location 
after  being  released  from  a  task,  its  equipment  and  manpower  are  also 
returned  to  the  parent  unit,  and  the  task  unit  is  dissolved. 

(18)  Block  L13.  EUPDAT  updates  all  engineer  tasks  prior  to  the 
completion  of  a  period  which  allows  the  report  processor  to  more  closely 
describe  the  tasking  status  at  the  end  of  a  period. 

3.  ROUTINE  EPRIOR: 

a.  Purpose.  The  routine  EPRIOR  determines  if  a  task  must  be  terminated 
due  to  the  proximity  to  the  FEBA,  or  because  of  a  direct  DSL  command.  If 

a  task  passes  both  criteria,  it  is  passed  to  routine  PRORTY.  Control  returns 
to  EPRIOR  to  process  tasks  in  the  queue. 

b.  Input  Variables.  In  addition  to  the  variables  standard  to  the 
overlay,  EPRIOR  requires  the  following  input: 


Name 

Source 

Contents 

FCEPT 

DF16 

Y  intercept  of  FEBA. 

SLOPE 

ONE 

Slope  of  line  perpendicular  to  FEBA. 

c. 

and  the 

Output  Variables.  Output 
following: 

includes  variables  standard  to  the  overlay 

Name 

Destination 

Contents 

PTYLTO 

DF18 

Zero  record  to  clear  file  area. 

d. 

Logical  Flow  (Figure  IV-14 

-B-2)  : 

(1)  Block  1.  After  routine  ENGR  has  placed  all  engineer  tasks  on 
the  priority  record  of  data  file  18  with  each  task  having  a  separate  record, 
routine  EPRIOR  brings  in  the  number  of  records  on  data  file  18  which  was 
stored  in  data  file  16. 

(2)  Blocks  2  and  3.  Obtain  the  intercept  of  the  FEBA  (intersection 
of  forward  battle  line  with  the  X  axis) ,  and  calculate  where  the  FEBA  will 
intersect  the  Y  axis  (YCEPTF) . 

(3)  Blocks  4,  L200,  Lll,  and  L21.  If  this  task  is  a  conditional 
task  or  a  Movement  Model  request,  it  is  the  only  task  to  be  examined  at  this 
time.  Control  bypasses  the  loop  established  in  block  L200  to  bring  in  only 
this  task's  priority  record.  Control  then  transfers  to  block  5.  Otherwise, 
begin  the  loop  with  block  L200  and  bring  in  the  data  file  18  record  for  each 
task. 

(4)  Blocks  5,  6,  and  7.  After  bringing  in  the  appropriate  barrier 
record,  routine  PONTLN  determines  the  distance  from  each  endpoint  to  the 
FEBA.  The  closer  distance  will  be  used. 
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Figure  IV-14-B-2.  Routine  EPRIOR  (Continued  on  Next  Page) 
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(5)  Blocks  8,  9,  and  L70.  To  determine  if  the  task  is  beyond  the 
FEBA,  get  a  front-line  unit  from  data  file  16  to  determine  Red  and  Blue 
orientation  to  the  FEBA.  If  the  task  is  within  1000  meters  of,  or  beyond  the 
FEBA,  transfer  control  to  ERELEA  to  release  equipment,  supplies,  and  manpower 
for  other  tasks  and  control  goes  to  block  L300.  If  not,  the  flow  continues 
at  block  L5. 

(6)  Blocks  L5  and  10.  If  the  task  was  a  DSL-ordered  stop  task, 
transfer  to  routine  ERELEA.  If  not,  control  transfers  to  L31. 

(7)  Block  L300.  To  prevent  further  action  on  this  task,  remove  the 
task  from  data  file  18  and  move  each  task  priority  forward  one.  Reduce  the 
number  of  records  on  data  file  18  by  one  and  place  it  on  data  file  16. 

Continue  processing  each  task  by  transferring  control  to  block  L200. 

(8)  Block  L31.  Routine  PRORTY  calculates  manhours  required,  priority 
of  task,  and  starting  time.  Control  transfers  to  block  L200. 

4.  ROUTINE  PRORTY: 

a.  Purpose.  Within  this  routine,  the  task  starting  time  is  calculated 
if  not  specified  by  DSL,  the  manhours  required  are  approximated,  and  a  task 
priority  is  assigned. 

b.  Input  Variables.  Standard  overlay  variables  and  the  following 
other  variables  are  input. 


Name 

Source 

Contents 

IFORCE 

DF16 

Indicator  designating  the  advancing 
force . 

SUNRIS 

DF4 

Beginning  morning  nautical  twilight 
(BMNT) • 

SUNSET 

DF4 

Ending  evening  nautical  twilight  (EENT) 

J 

Call 

Current  data  file  18  record. 

c. 

Output  Variables. 

Standard  overlay  data. 

d.  Logical  Flow  (Figure  IV-14-B-3): 

(1)  Block  LI.  Determine  task  priority.  If  this  is  a  mandatory 
task,  control  transfers  to  block  L10. 

(2)  Blocks  1  and  2.  If  it  is  not  a  mandatory  task,  compute  the 
first-digit  priority  based  on  which  is  the  advancing  force  which  force  is  to 
execute  the  task,  whether  the  structure  is  a  bridge/facility  or  a  barrier,  and 
whether  it  is  a  build  or  breach  task.  The  advancing  force  is  obtained  from 
data  file  16.  Control  transfers  to  block  3. 
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Figure  IV-14-B-3. 


Routine  PRORTY  (Continued  on  Next  Page) 
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Figure  IV-14-B-3.  Routine  PRORTY  (Continued) 
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Figure  IV-14-B-3. 


Routine  PRORTY  (Concluded) 
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(3)  Blocks  3  and  4.  If  Che  task  is  in  progress,  control  transfers 
to  block  L250.  If  not,  determine  if  required  manhours  and  starting  time  have 
been  calculated.  If  so,  control  transfers  to  block  L200. 

(4)  Block  5.  Routine  IRECN1  calculates  the  standard  required 
number  of  troop  units,  the  standard  accomplishment  rate,  and  the  physical 
task  size  for  this  task,  and  determines  the  task  record  number. 

(5)  Blocks  6,  L190,  and  8.  To  compute  the  total  manhours  required 
for  this  task,  first  determine  an  average  number  of  men  per  unit  as  specified 
in  the  troop  unit  type  that  is  consistent  with  the  unit  rates  specified  with 
the  associated  unit  rate  loaded  on  data  file  17.  Because  smaller  amounts 

of  equipment  are  required  to  finish  a  breached  structure  or  to  breach  an 
existing  structure,  the  size  magnitude  of  the  task  will  be  internally  diminished 
to  lessen  the  task  requirements.  The  manhours  required  are  determined. 

(6)  Blocks  L33,  9,  10,  11,  and  12.  Compute  the  starting  time  for 
the  task.  If  this  task's  starting  time  is  DSL  specified,  control  transfers 

to  block  L200;  otherwise,  determine  the  standard  time  required  to  complete  this 
task,  traf f icability  rate  modifer  from  data  file  17  (given  the  current 
terrain  data  from  routine  IOTERN),  and  nighttime  modifer,  if  applicable. 

Modify  the  standard  time  by  these  modifiers  to  gain  an  adjusted  time  required. 
Subtract  this  adjusted  time  from  the  DSL  specified  completion  time. 

(7)  Blocks  L200,  13,  and  14.  To  compute  the  time  priority  code, 
subtract  the  current  battle  time  from  the  task  start  time  just  calculated,  and 
divide  this  time  into  60-minute  increments,  with  each  increment  increasing 
the  priority  code  by  one  (up  to  four) .  If  the  task  is  to  be  executed  during 
this  pass  through  the  Engineer  Model,  an  appropriate  flag  is  set  to  be 
checked  later  in  routine  FESBIL. 

(8)  Block  15.  Compute  task  priority  based  on  force  priority  from 
block  2,  time  priority,  and  DSL  priority.  Return  barrier  record  to  data 
file  2. 


(9)  Block  L250.  Rank  tasks  on  the  priority  record  from  highest 
priority  to  lowest,  with  mandatory  tasks  in  progress  ranked  prior  to 
desired  ones  in  progress.  When  the  priority  record  has  been  reranked  and 
all  records  replaced  in  data  file  18,  control  returns  to  the  calling  routine. 

5.  ROUTINE  EFEASI : 

a.  Purpose.  This  routine  determines  the  brigade  area  of  responsibility 
where  the  task  is  located,  and  drives  the  routines  for  selecting  manpower 
for  the  task  and  for  allocating  the  necessary  equipment  and  supplies  required 
from  the  company/or  the  battalion.  EFEASI  issues  movement  orders  to  get 
task  units  and  equipment  to  the  sice. 
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b.  Input  Variables.  In  addition  to  the  overlay  data,  other  variables 


are: 

Name 

Source 

Contents 

SLOPE 

ONE 

Slope  of  line  perpendicular  to  FEBA. 

IGEOM 

DF16 

Y  intercepts  and  IUIDs  ranked  and 
increasing  monotonically  for  both  Blue 
and  Red  forces. 

II 

DF16 

Number  of  tasks  in  queue  for  Engineer 
Model. 

KL 

DF16 

Number  of  front-line  brigades. 

IUNTLC 

TOO 

Location  table  for  all  units. 

IUTD 

TOO 

UTDs  of  all  units. 

JARRAY 

DF51 

List  of  UTDs  linking  movement  information 
on  data  files  8  and  9. 

MOBCAT 

DF9 

INDXEX 

DF9 

Variables  used  by  the  Movement  Model 

IREC8 

DF8 

in  generating  logic  for  movement  segments 

c.  Output  Variables.  Standard 

overlay  data  and  the  following  other 

variables: 

Name 

Destination 

Contents 

IXACT 

TOO 

X  coordinate  of  resolution  unit. 

IYACT 

TWO 

Y  coordinate  of  resolution  unit. 

d.  Logical  Flow  (Figure  IV-14-B-4) : 

(1)  Blocks  LI,  1,  1.201,  and  2.  On  data  file  16  is  stored  the 
current  number  of  engineer  tasks  that  have  been  requested  by  the  Movement 
Model  and  through  DSL.  If  entry  to  this  routine  is  not  start-of-period 
initiation  or  regular  updating,  only  one  specific  task  is  examined;  otherwise, 
all  tasks  are  examined.  The  one  particular  task  record  on  data  file  18  will 

be  passed  in  common,  from  which  the  priority  record  is  obtained;  otherwise, 
examine  all  tasks  on  data  file  18  sequentially. 

(2)  Blocks  L1001  and  L203.  After  bringing  in  the  proper  barrier  record 
from  data  file  2,  EFEASI  checks  the  requested  task  to  guarantee  no  errors 

have  occurred;  e.g.,  requesting  a  build  task  where  the  structure  already 
exists,  or  requesting  a  task  at  an  unbreachable  task  site. 
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Figure  IV-14-B-4.  Routine  EFEASI  (Continued  on  Next  Page) 
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Figure  IV-14-B-4 . 


Routine  EFEASI  (Concluded) 
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(3)  Block  L110.  After  bringing  in  the  brigade  areas  of  responsibility 
for  Red  or  Blue  force,  search  this  list  to  locate  the  area  where  most  of  the 
task  is  to  be  performed.  If  no  area  of  responsibility  is  found,  default  is 
automatically  made  to  the  division  area  as  a  whole. 

(4)  Block  4.  After  determining  where  to  begin  searching  for  units, 
routine  MPRALC  selects  the  necessary  units;  if  some  units  have  been  previously 
assigned,  available  units  that  bring  the  troop  level  up  to  the  required  number 
are  selected.  If  the  unit  selected' to  be  record  does  not  exist  on  data  file  1, 
the  unit's  status  record  is  created. 

(5)  Block  5.  If  the  task  is  in  progress,  control  transfers  to 
block  L130. 

(6)  Block  L22.  If  the  task  is  not  begun,  or  unit  has  not  been 
directed  toward  the  task,  allocation  of  necessary  equipment  is  made  by 
routine  FESBIL. 

(7)  Blocks  6  and  L115.  Control  transfers  to  Block  L130  if  troops 
or  equipment  were  allocated.  If  not,  a  flag  is  set  to  allow  no  allocation 
of  equipment  to  desired  tasks  of  lower  priority. 

(8)  Blocks  L130,  7,  and  L133.  A  pseudo  DSL  movement  order  is 
generated  for  the  Movement  Model  to  include  establishing  actual  coordinates 
for  the  unit,  objective  point,  and  proper  movement  codes  and  rates,  and 
transferring  control  to  routine  UPMASK  to  develop  a  masking  function  for 
this  unit,  placing  its  present  location  into  common,  and  placing  the 
movement  event  into  the  unit's  event  table. 

(9)  Block  L601.  Allocate  fuel  for  movement  of  this  unit  to  and 
from  the  task  site  and  during  performance.  Replace  the  unit's  status  record 
on  data  file  1.  Repeat  this  process,  transferring  control  to  block  L130 
until  movement  orders  have  been  generated  for  all  task  units;  then,  return 
to  block  2  to  process  next  task. 

6.  ROUTINE  FESBIL: 

a.  Purpose.  This  routine  allocates  the  equipment  and  supplies  to 
perform  the  requested  task.  It  determines  whether  contingency  requirements 
apply  to  this  particular  task,  and  allocates  available  supplies  from  the 
parent  unit  at  company  level.  If  this  is  insufficient,  it  allocates  what  is 
available,  up  to  the  amount  required,  from  the  battalion  level.  It  then 
creates  the  proper  entries  for  this  task's  data  file  37  record  and  updates 
the  mission  unit's  data  file  50  record  for  authorized  strength,  based  on 
the  amount  of  each  item  code  required. 

b.  Input  Variables. 

(1)  Standard  overlay  data. 
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(2) 

Other  Variables: 

Name 

Source 

Contents 

ITYPIC 

DF17 

Item  code  array  for  this  task  type. 

IOUT 

DF50 

Authorized  strengths  by  item  code. 

ICNTGY 

DF17 

Contingency  amount  for  each  item  code 
type. 

c. 

Output  Variables: 

(1) 

Standard  overlay  data. 

(2) 

Other  Variables: 

Name 

Destination 

Contents 

IXLFT1 

DF37 

Amount  of  equipment  borrowed. 

IOVT 

DF50 

New  authorized  strengths  record. 

d.  Logical  Flow  (Figure  IV-14-B-5) : 

(1)  Blocks  1,  2,  anu  3.  Bring  in  the  status  record  of  the  mission 
unit  and  its  borrowed  equipment  array  from  data  file  37.  Bring  in  the  task 
equipment  array  based  on  the  record  number  on  data  file  17  returned  from 
routine  IRECN1. 

(2)  Block  L45.  Determine  equipment  and  supplies  currently  on  hand 
in  all  task  units,  then  return  the  status  record  of  the  mission  unit  to 
core. 

(3)  Blocks  L50,  L41,  and  5.  Begin  looping  on  all  item  codes  required 
for  the  task.  Calculate  the  quantity  of  equipment  needed  for  this  task, 

then  subtract  the  amount  currently  on  hand  from  the  amount  needed.  If  enough 
equipment  is  on  hand  for  this  item  code,  control  transfers  to  block  14. 

(4)  Blocks  6  and  7.  If  sufficient  quantity  of  equipment  is  not  on 
hand,  determine  whether  contingency  applies,  and  based  on  this  contingency 
calculate  the  amount  of  equipment  available  in  the  company  and  battalion 
levels.  If  the  amount  available  in  the  compary  meets  the  requirement, 
control  transfers  to  block  10. 

(5)  Blocks  L5002  and  8.  If  there  is  insufficient  equipment  at 
company  level,  allocate  what  is  available,  keep  contingency  in  reserve  from 
the  company,  and  determine  if  the  remaining  required  amounts  can  be  obtained 
from  the  battalion  level.  If  the  battalion  has  enough  equipment,  less 
contingency,  control  transfers  to  block  10. 

(6)  Block  9.  If  the  battalion  does  not  have  the  required  equipment, 
allocate  what  is  available  and  transfer  control  to  block  L38. 
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Figure  IV-14-B-5.  Routine  FESBIL  (Continued  on  Next  Page) 
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Figure  IV-14-B-5.  Routine  FESBIL  (Continued) 
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(7)  Blocks  10,  11,  and  L38.  Allocate  the  equipment  still  needed  and 
continue  the  loop. 

(8)  Blocks  12,  L70,  and  13.  If  there  are  no  more  item  codes  to 
consider,  return  the  status  record  of  the  mission  unit  and  status  records  of 
the  company  and  battalion  where  supplies  were  obtained  to  data  file  1,  output 
the  borrowed  equipment  array,  and  generate  an  authorized  strength  record 

for  data  file  50. 

(9)  Block  L51.  Return  the  barrier  record  for  this  task  to  data  file 
2.  Return  control  to  the  calling  routine. 

7.  ROUTINE  ERELEA: 

a.  Purpose.  ERELEA  is  called  when  termination  of  a  task  is  required,  due 
to  completion,  stop  order  through  DSL,  or  proximity  to  the  FEBA.  This 
routine  updates  information  concerning  tasking  and  current  existance 

and  intelligence  information  on  the  barrier  file,  and  generates  movement 
orders  to  return  task  units  to  parent  units. 

b.  Input  Variables: 

(1)  Standard  overlay  data. 

(2)  Other  variables: 


Name 

Source 

Contents 

IALFA 

Call 

Reason  for  task  termination. 

ITYPIC 

DF17 

Item  codes  used  by  this  activity  and 
this  task  type. 

JARRAY 

DF51 

List  of  UTDs  providing  link  to  word 
locations  on  data  files  8  and  9. 

MOBCAT 

INDXEX 

IREC8 

DF9 

DF9 

DF8 

Used  by  Movement  Model  as  qualifier  for 
type  of  movement  desired. 

c. 

Output  Variables: 

UMAIN  and  I ARRAY. 

d.  Logical  Flow  (Figure  IV-14-B-6): 

(1)  Block  1.  Update  barrier  record  to  indicate  reason  for  termination 

of  task. 

(2)  Block  L23.  Bring  in  unit  status  record  of  mission  unit  from 
data  file  1. 
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Figure  IV-14-B-6. 


Routine  ERELEA  (Continued) 
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Figure  IV-14-B-6.  Routine  ERELEA  (Concluded) 
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(3)  Blocks  2,  L22,  3,  and  4.  After  determining  the  proper  record 
number  on  data  file  17,  bring  in  the  task's  equipment  requirement  from 
data  file  17  and  the  borrowed  equipment  array  from  data  file  37.  If  no 
equipment  for  this  task  was  obtained  from  the  battalion,  transfer  control  to 
block  10;  otherwise,  processing  continues  to  block  5. 

(4)  Block  5.  Bring  in  unit  status  record  for  battalion. 

(5)  Blocks  L30,  6,  7,  8,  and  L31.  Based  on  the  ratio  between  the 
amount  of  an  equipment  item  borrowed  from  company  level  and  the  amount  of  the 
same  equipment  item  borrowed  from  the  battalion,  return  that  proportion  of 
equipment  still  on  hand  in  keeping  with  this  ratio  to  the  battalion  and 
remove  this  amount  of  equipment  from  the  mission  unit's  supply. 

(6)  Block  9.  Decrement  appropriate  amount  of  fuel  to  allow 
equipment  to  be  returned  to  parent  unit.  If  additional  items  are  to  be 
considered,  transfer  control  to  block  L30. 

(7)  Blocks  10  and  L75.  If  Movement  Model  has  requested  this  task, 
advise  the  model  so  that  movement  may  continue. 

(8)  Blocks  L72  and  11.  A  simulated  DSL  movement  order  is  generated 
for  each  task  unit  on  site.  If  a  parent  unit  cannot  accept  the  task  unit, 
each  task  unit  is  given  a  stay  order  and  becomes  available  for  additional 
engineer  tasks. 

(9)  Blocks  L81,  L90,  and  12.  Return  unit  status  record  for  each 
unit  to  data  file  1,  zero  the  appropriate  data  file  37  record,  and  update 
existence,  intelligence,  and  troop  status  on  the  barrier  record.  Return 
control  to  the  calling  routine. 

8.  ROUTINE  EUPDAT: 

a.  Purpose: 

(1)  After  general  task  initiation  and  allocation  at  the  start  of 

a  period,  routine  EUPDAT  becomes  the  overall  controller  of  the  Engineer  Model. 
After  EUPDAT  is  notified  a  tasked  unit  has  reached  its  destination,  it 
calculates  the  modified  task  rate  due  to  terrain,  night,  and  lack  of  equipment. 
From  this  modified  rate,  the  routine  calculates  the  total  manhours  expended 
since  the  last  update  and  proportions  loss  of  expendable  equipment  among  all 
units  on  site.  The  routine  prorates  the  amount  of  expendable  equipment  and 
determines  the  amount  of  nonexpendable  equipment  still  required  to  complete 
the  task.  It  resupplies  the  mission  unit  with  supplies  still  needed  by 
inquiring  at  the  company  level  and  the  battalion  level.  If  a  task,  after  being 
updated,  is  completed,  the  manpower  and  supplies  are  released  for  other 
taaks.  This  task  is  removed  from  the  priority  table,  and  remaining  priority 
tasks  are  reranked. 

(2)  For  a  task  not  underway,  EUPDAT  transfers  control  to  the  PRORTY 
routine  to  determine  the  priority  for  the  considered  task  and  rank  the 
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priority  table.  Units  still  moving  to  task  sites  are  given  adjusted  pointers 
to  respective  priority  records.  EUPDAT  generates  the  next  entry  into  routine 
PRORTY  in  15  minutes. 

b.  Input  Variables. 

(1)  Standard  Engineer  Model  variables. 

(2)  Other  variables: 


Name 

Source 

Contents 

II 

DF16 

Number  of  priority  tasks  on  data  file  18. 

JREC37 

DF1 

Pointer  on  status  record  of  mission  unit 
to  its  data  file  37  record. 

ITRRIG 

DF17 

Terrain  rate  modifier  for  this  task  type. 

ISNRSE 

DF4 

Beginning  morning  nautical  twilight  (BMNT) 

ISNSET 

DF4 

Ending  evening  nautical  twilight  (EENT) 

IOYRTE 

DF17 

Night  rate  modifier  for  this  task  type. 

ITYPIC 

DF17 

Data  file  17  record  for  this  task  type. 

IPOL 

DF15 

Fuel  consumption  rate  for  the  particular 
item  code. 

LGTPER 

ONE 

Length  of  period. 

c. 

Output  Variables: 

(1) 

Variables  standard 

to  the  Engineer  Model. 

(2) 

Other  variables: 

Name 

Destination 

Contents 

IPTYLO 

DF18 

A  zero-filled  priority  record  to  free  and 
rank  data  file  18. 

d. 

Logical  Flow  (Figure  IV- 

-14-B-7): 

on  data 

(1) 

file 

Blocks  1  and  L110. 
18.  If  this  is  an 

Obtain  the  number  of  valid  priority  tasks 
update  interruption  caused  by  a  unit  arriving 

first  at  the  task  site,  only  one  task  priority  record  on  data  file  18  must 
be  examined;  otherwise,  begin  looping  on  all  records  on  data  file  18. 
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Figure  IV-14-B-7. 


Routine  EUPDAT  (Continued  on  Next  Page) 
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Figure  IV-14-B-7.  Routine  EUPDAT  (Continued) 
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Figure  IV-14-B-7.  Routine  EUPDAT  (Concluded) 
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(2)  Blocks  Lll,  3,  and  4.  After  bringing  in  the  priority  record  for 
the  task  to  be  analyzed  and  the  barrier  record  for  this  task,  routine  PRORTY 
determines  the  priority  of  this  task  and  reorganizes  priorities  on  data 
file  18. 


(3)  Blocks  L21  and  5.  If  entry  has  been  made  into  EUPDAT  for  the 
end-of-period  update,  the  starting  times  of  engineer  tasks  not  begun  are 
reset  to  indicate  tasks  have  been  held  over  from  the  previous  period;  control 
is  transferred  to  block  9  after  the  priority  table  has  been  returned  to 

data  file  18. 

(4)  Blocks  L-2  and  L70.  Having  recalculated  this  task's  priority, 
control  transfers  to  block  L10  if  the  task  is  not  yet  in  progress  and 
continues  to  the  next  task.  If  the  task  is  in  grogress,  but  the  mission 
unit  has  not  arrived  at  the  task  site,  control  again  transfers  to  block  L10; 
otherwise,  control  transfers  to  routine  IRECN1  where  the  proper  record  on 
data  file  17  and  task  size  are  calculated. 

(5)  Block  L20.  Routine  MPRUPD  returns  the  number  of  personnel 
currently  working  at  task  site,  the  decision  whether  to  use  the  minimum 

or  standard  troop  rate,  and  the  average  number  of  personnel  per  unit  of  this 
size.  Get  the  task  rate  from  its  proper  location  in  arrav  ITYPIC  fret",  data 
file  17. 


(6)  Blocks  5  and  L183.  Modify  this  rate  by  terrain  or  nighttime 
limitations  to  working  conditions,  and  multiplicatively  calculate  the 
modifier  due  to  smaller  amounts  of  equipment  available  than  needed.  Calculate 
the  time  since  last  update. 

(7N  Block  6.  Using  the  modified  rate  obtained  above,  calculate 
the  manhours  expended  since  the  last  time  this  task  was  updated. 

(8)  Blocks  L390  and  L30.  Given  the  new  modified  task  rate, 
decrease  the  fuel  and  expendable  supplies  to  allow  for  consumption  since  the 
update,  and  proportion  among  units  at  the  task  site. 

(9)  Blocks  L38,  L28,  L150,  L300,  and  7.  If  a  task  has  not  been 
completed,  control  transfers  to  block  8.  If  it  is  completed  routine  ERELEA 
releases  manpower  and  supplies  for  other  tasks  and  the  barrier  record  for 
this  task  is  updated.  Units  that  may  still  be  moving  to  this  task  site 
are  intercepted  and  freed  for  other  tasks.  This  record  is  removed  from  the 
priority  file,  the  number  of  tasks  on  the  file  is  reduced  by  one,  and  the 
new  value  is  returned  to  data  file  16.  Control  transfers  to  block  L10. 


(10)  Block  8.  Examine  the  amount  of  equipment  on  hand  and  the  amount 
required  to  complete  the  task.  If  the  amount  on  hand  is  insufficient, 
allocate  what  is  still  required  first  on  the  company  level,  then  on  the 
battalion  level,  by  prorating  the  expendable  equipment  still  needed  versus 
the  amount  on  hand  and  using  the  difference  for  nonexpendable  equipment. 


C 


(11)  Block  L120.  Reset  all  pointers  for  units  moving  to  task 
sites  to  point  to  the  proper  data  file  18  record  for  this  unit. 


IV-14-B-37 


(12)  Blocks  L10,  9,  and  10.  Replace  data  files  1,  2,  1^  and  37  for 
this  task  and  determine  if  there  are  more  tasks  to  be  analyzed.  If  there 
are,  control  goes  to  block  L110.  If  not,  the  next  entry  into  the  Engineer 
Model  is  scheduled  and  control  returns  to  the  calling  routine. 

9.  ROUTINE  BUIDRC.  Routine  BUIDRC  converts  the  mnemonic  associated  with 
any  barrier  into  the  record  number  on  data  file  2.  This  is  an  alphebetic 
scheme  that  assigns  to  each  type  of  mnemonic  a  certain  number  of  locations 
on  data  file  2,  regardless  of  whether  they  are  used.  The  logic  in  assigning 
the  current  number  of  records  per  mnemonic  has  been  designed  to  best  utilize 
the  space  available. 

10.  ROUTINE  CREA16 : 

a.  Purpose.  To  establish  areas  of  responsibility  for  front-line 
brigades  assigned  engineer  tasks,  it  is  necessary  for  the  Engineer  Model  to 
follow  the  movement  of  these  front-line  brigades  to  constantly  know  the 
flanking  boundaries  of  these  units;  therefore,  routine  CREA16  periodically 
ranks  the  front-line  brigades  of  both  forces  by  their  Y  intercepts  (intercept 
of  a  line  denoting  flanking  boundaries  with  the  Y  axis)  from  smallest  to 
largest  and  stores  this  information  for  reference  by  routine  EFEASI  in 
data  file  16. 


b. 

Input  Variables: 

(1)  Standard  variables  to  the  Engineer  Model. 

(2)  Other  Variables: 

Name 

Source 

Contents 

IUDFNT 

DF16 

Blue  front-line  brigades  or  Red  front¬ 
line  brigades. 

RPOINT 

ONE 

Identification  of  last  Red  unit. 

c. 

Output  Variables: 

Name 

Destination 

Contents 

IGEOMB 

DF16 

List  of  Blue  front-line  brigades  and 
their  Y  intercepts  (YCEPT) . 

IGEOMR 

DF16 

List  of  Red  front-line  brigades  and 
their  Y  intercepts. 

d. 

Logical  Flow  (Figure 

IV-14-B-8) : 

(1)  Block  1.  Bring 

in  a  maximum  of  eight  front-line  brigades  from 

data  file  16  for  both  Blue  and  Red  forces.  Total  the  number  of  actual 
front-line  brigades  of  each  force. 
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Figure  IV-14-B-8.  Routine  CREA16 


(2)  Block  Lll.  Routine  GEOM  examines  each  front-line  brigade,  gets 
its  YCEPTs,  and  compares  the  YCEPTs  with  those  on  the  list,  ranking  the 
brigade  from  lowest  to  highest  YCEPT. 

(3)  Block  2.  Store  the  brigades  and  their  Y  intercepts  onto  data 

file  16. 

11.  ROUTINES  EQPT  and  EQPTUP.  Routine  EQPT  allocates  equipment  that  is 
still  needed.  It  is  called  by  EQPTUP  which  sets  the  level  of  resolution  from 
where  the  equipment  will  be  sought;  i.e.,  the  first  call  to  EQPT  is  for 
company  level,  the  second  is  for  the  battalion.  EUPDAT  passes  EQPTUP  the 
item  code  needed  (IK),  the  amount  needed  (EOHDLT) ,  which  force  is  to  execute 
the  task  (JI)  ,  the  battalion  level  unit  from  which  equipment  can  be  obtained 
(IB0SS1),  with  the  company  level  unit  passed  in  UCOOP  and  the  mission  unit  in 
UMAIN,  and  the  transportation  item  code  of  this  equipment  type.  EQPTUP 
calls  EQPT,  first  with  the  company  level  unit  in  UCOOP,  and  second  with 

the  battalion  level  unit  in  UCOOP.  EQPT  goes  to  any  applicable  contingency 
for  this  item  code  and  allocates  to  the  mission  unit  any  available  equipment 
considering  the  contingency.  EQPT  allocates  all  that  is  available  if  the 
unit  has  insufficient  supplies  and  returns  the  amount  allocated  in  EOHOLT. 

It  deducts  fuel  that  will  be  expended  in  moving  the  equipment  to  the  mission 
unit  from  the  unit  from  which  the  equipment  was  obtained. 

12.  ROUTINE  GEOM.  Routine  GEOM  is  passed  the  list  of  front-line  brigades 
of  each  force.  It  brings  the  designated  unit  status  record  into  UMAIN  and 
compares  its  Y  intercepts  with  those  previously  brought  in.  Based  on  this 
comparison,  the  brigades  are  ranked  by  YCEPTs,  in  ascending  order,  and 
the  brigades  and  their  YCEPT  values  are  returned  in  IGEOM. 

13.  ROUTINE  IRECN1.  The  force  to  execute  a  task  and  the  task  type  are 
passed  to  IRECN1.  It  calculates  the  record  number  for  this  task  on  data 
file  17  and  gets  the  basic  size  of  this  task.  It  returns  the  standard  number 
of  troop  units  required  (ISTTRP) ,  standard  rate  for  this  task,  and  the 
physical  size  of  this  task  (SIZE1). 

14.  ROUTINE  MPRALC : 


a.  Purpose.  This  routine  allocates  the  units  necessary  for  a  task  by 
checking  the  brigade  area  and  the  entire  division.  It  ranks  available  units 
for  the  task  on  a  nearest-to-task-site  basis,  and  assigns  units  to  the  task 
until  the  required  number  is  met. 

b.  Input  Variables; 


(1)  Variables  standard  to  the  overall  Engineer  Model. 

(2)  Other  Variables: 


Name 


Source 


Contents 


JI  Call 

ISTTRP  Call 


Force  to  execute  task. 

Standard  number  of  task  units  required. 
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Name 

Source 

Contents 

IBRDE1 

Call 

Brigade  unit  in  area  of  responsibility. 

INORD 

DF1 

Order  code  of  units  subordinate  to  each 
subordinate  unit  of  IBRDE1. 

JUTD 

TWO 

Unit  type  designator  of  units  subordinate 
to  each  subordinate  unit  of  IBRDE1. 

IIUID 

DF37 

Engineer  unit  assigned  to  atomic 
demolition  munition  (ADM)  tasks. 

RPOINT 

ONE 

Pointer  to  last  Red  unit  on  data  file  1. 

c. 

Output  Variables: 

(1) 

Standard  Engineer  Model 

variables . 

(2) 

Other  Variables: 

Name 

Destination 

Contents 

IPNTR 

Call 

Flag  for  insufficient  troop  units  found. 

IIUID 

DF37 

Engineer  unit  assigned  to  ADM  tasks. 

d.  Logical  Flow  (Figure  IV-14-B-9) : 

(1)  Blocks  1,  2,  and  3.  If  this  task  was  requested  by  the  Movement 
Model,  examine  those  units  subordinate  to  the  unit  requesting  the  task  for  a 
suitable  unit  available  for  the  task.  If  there  are  no  units  available, 
control  goes  to  routine  SET37  to  create  a  data  file  37  record  for  this  task. 

If  this  satisfies  the  troop  requirements,  control  goes  to  block  L501. 

(2)  Blocks  L1205,  L1230,  L1270,  and  5.  If  this  was  not  a  Movement 
Model  request,  or  the  number  of  units  required  is  not  satisfied,  examine  the 
task  for  its  location  within  a  front-line  brigade's  area  of  responsibility. 

If  it  is  not  the  responsibility  of  a  brigade,  control  transfers  to  block 
L1300.  If  it  is,  check  the  units  subordinate  to  the  brigade  for  the  proper 
type  unit.  If  any  are  found,  control  goes  to  routine  SET37  and  block  3. 

If  no  suitable  units  subordinate  to  the  brigade  are  found,  check  for 
complex  units  that  are  available  for  the  task.  If  any  are  found,  control 
transfers  to  routine  UNTORG,  that  detaches  the  complex  unit  from  its  parent 
and  creates  a  unit  status  record,  data  file  1,  for  this  unit.  If  the  required 
number  of  units  are  now  allocated,  control  transfers  to  block  L501. 

(3)  Block  L1300.  If  the  proper  number  of  troop  units  are  still 

not  allocated,  check  the  remainder  of  the  division.  From  those  units  that  are 
suitable  and  available  for  the  task,  rank  them  from  closest  to  farthest  from 
the  task  site. 
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Figure  IV-14-B-9. 


Routine  MPRALC  (Continued  on  Next  Page) 
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(4)  Block  L1600.  Examine  and  allocate  units  beginning  at  top  of  list 
until  either  the  requirements  are  met  or  the  list  is  exhausted. 

(5)  Blocks  L1061  and  L1062.  If  units  are  found  to  be  available,  and 
they  are  not  complex,  control  transfers  tn  routine  SET37.  If  it  is  a 
complex  unit,  routine  UNTORG  is  called,  11  troop  requirements  are  still  not 
met,  continue  looking  and  control  goes  back  to  block  L1600. 

(6)  Block  L501.  Upon  allocating  the  required  number  of  troops, 
examine  the  troop  type  required  to  see  if  engineer  companies  are  required 
with  bridging  platoons.  If  so,  control  returns  to  block  1  and  the  above 
process  is  repeated;  if  not,  replace  the  barrier  file  and  return  control  to 
the  calling  routine. 

15.  ROUTINE  MPRUPD.  MPRUPD  is  called  from  EUPDAT  and  sums  the  current 
number  of  personnel  (NUMCUR)  in  all  units  assigned  at  the  task  site.  It  also 
sets  ITRTYP,  the  troop  type  indicator,  and  NNUM,  the  average  number  of  personnel 
per  unit.  If  there  are  fewer  units  at  the  site  than  required,  IRATE  is  set 

to  indicate  that  the  minimum  task  rate  is  to  be  used.  These  four  variables 
are  returned  in  the  calling  sequence. 

16.  ROUTINES  STUNIT  and  SET37.  Routine  SET37  examines  units  that  are  ready 
for  allocation  to  guarantee  that  no  unit  is  selected  for  tasking  unless  it 
has  at  least  50  percent  of  its  authorized  strength.  If  the  unit  passes  this 
test  and  is  to  be  the  mission  unit  allocated,  control  goes  to  routine  STUNIT. 

If  not,  the  pointer  to  data  file  37  for  this  task  is  obtained  from  the  status 
record  of  the  mission  unit  and  placed  on  this  unit’s  status  record  and  control 
returns  to  the  calling  routine.  Routine  STUNIT  goes  to  the  first  word  on 

the  first  record  of  data  file  37  to  find  the  next  vacant  record  on  data  file 
37  to  affiliate  with  this  task.  It  places  this  record  number  in  word  421  of 
the  mission  unit's  status  record  and  increases  by  one  the  first  word  of  the 
first  record  of  data  file  37  and  returns  control  to  the  calling  routine. 

17.  ROUTINE  UNTORG.  If  a  unit  is  suitable  for  the  task,  but  is  still 
inherent  to  its  parent  unit,  the  routine  UNTORG  detaches  the  unit  from  its 
parent,  creates  a  new  unit  status  record  for  it,  places  this  record  on  data 
file  1,  adjusts  BPOINT  or  RPOINT,  and  places  all  related  information,  such 

as  UID,  UTD,  and  location,  in  common.  If  the  parent  unit  is  not  a  resolution 
unit,  UNTORG  also  gives  the  parent  unit  coordinates  and  personnel  and  distri¬ 
butes  its  equipment.  UNTORG  then  calls  SET37  for  this  newly  created  unit's 
status  record  and  puts  the  record  on  data  file  1. 

18.  ROUTINE  CRTQD.  This  routine  creates  an  eight-digit  code  based  on  the 
location  of  either  a  line  segment  or  a  circle.  If  a  circle  is  passed  to 
the  routine  by  giving  the  coordinates  of  the  center  of  the  circle  and  its 
radius,  two  perpendicular  lines  are  created,  each  line  the  length  of  the 
diameter  of  the  circle  and  intersecting  at  its  center;  if  a  line  is  passed  by 
giving  its  two  endpoints,  that  line  is  used.  By  continuing  to  divide  a 
rectangle  into  four  equal  parts,  once  the  center  of  action  is  determined,  the 
location  of  each  line  in  relation  to  these  quadrants  is  obtained.  The  nine 
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possible  areas  where  a  barrier  line  or  circle  could  lie  in  one  quadrant  are 
shown  below.  A  barrier  intersecting  both  quadrants  1  and  2  is  said  to  lie 
in  area  5.  A  line  in  area  5,  6,  7,  8,  or  9  would  allow  no  further  refinement 
to  be  made  on  the  eight-digit  code;  so,  the  quadrature  code  would  be  complete. 
If,  however,  the  barrier  was  to  lie  in  area  1,  2,  3,  or  4 ,  this  value  would 
be  entered  in  the  quadrature  code,  and  this  region  would  continue  to  be 
subdivided  as  in  the  illustration.  When  the  eight-digit  code  has  been  completed 
completed  or  cannot  continue,  control  returns  to  the  calling  routine. 


Figure  IV-14-B-10.  Barrier  Quadrature  Example 


19.  ROUTINE  NUCSCH: 

a.  Purpose.  This  routine  determines  if  the  radius  of  effects  input  from 
the  Nuclear  Assessment  Model  will  intersect  a  barrier  line.  If  an  intersection 
is  found  and  the  effects  of  the  Nuclear  Assessment  Model  could  alter  the 
structure  of  the  barrier  the  intersection  is  returned  in  common  to  the  Nuclear 
Assessment  Model. 


b. 


Name 

IBIG1 

RAD 


Input  Variables: 

(1)  Standard  Common  Block  Variable.  UMAIN. 

(2)  Other  Variables: 

Source  Concents 

DF16  Geometry  for  quadrature  initiation. 

TWO  Radius  of  effects  to  be  searched. 
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Name 


Source 


Concents 


XCNT  TWO  X  coordinate  of  ground  zero. 

YCNT  TWO  Y  coordinate  of  ground  zero. 

IBIG  DF22  List  of  barrier  code  numbers  and  their 

locations . 

IOF(35)  DF2  Data  describing  the  barrier. 

c.  Output  Variables: 

Name  Destination  Contents 

OBFLST  DF16  List  of  barriers  intersecting  radius  of 

effects . 

INTNUM  DF16  Number  of  barriers  intersected. 

d.  Logical  Flow  (Figure  IV-14-B-11): 

(1)  Block  1.  The  routine  CRTQD  is  called  to  generate  the  eight-digit 
quadrature  code  associated  with  this  radius  of  effects.  The  quadrature  code 
describes  the  location  of  the  circLe  of  the  radiological  detonation. 

(2)  Block  L65.  The  quadratures  are  screened  to  determine  which 
contain  barrier  segments  intersecting  this  search  area.  Of  the  17  possible 
quadratures,  6  to  13  are  eliminated  by  this  method. 

(3)  Block  L60.  The  17  records  of  data  file  22  correspond  to  the  17 
quadratures.  Each  record  contains  the  barrier  records  and  quadrature  codes 
of  barriers  located  within  the  corresponding  quadrature.  The  appropriate 
record  is  retrieved  from  data  file  22. 

(4)  Block  L61.  If  this  quadrature  does  contain  barriers  to  be 
further  examined,  control  transfers  to  block  L500. 

(5)  Block  L70.  If  other  quadratures  are  to  be  searched,  parameters 
aiding  in  the  barrier-line/blast-area  intersection  check  are  reinitialized 
and  control  returns  to  block  L60;  otherwise,  control  goes  to  block  3. 

(6)  Block  L500.  If  the  quadrature  code  of  the  blast  area  does  not 
correspond  to  the  quadrature  code  of  this  barrier,  control  transfers  to 
block  L300. 

(7)  Block  L123.  Natural  barriers  that  will  not  be  affected  by 
the  blast  will  be  ignored. 

(8)  Blocks  L12Q  and  2.  The  utility  routine  INCRCL  is  used  to 
determine  if  the  barrier  line  and  blast  area  intersect.  If  they  do,  the 
barrier  record  number  is  stored. 
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(9)  Block  L300.  If  ocher  barriers  are  to  be  examined  in  this 
quadrature,  control  transfers  to  block  L500. 

(10)  Blocks  3  and  4.  If  any  barriers  are  intersected,  place  them 
in  common.  Control  is  returned  to  the  calling  routine. 

20.  ROUTINE  ENUCLE: 


a.  Purpose.  Routine  ENUCLE  generates  the  physical  structure  to  be 
associated  with  a  radiological  barrier. 


b. 

Input  Variables : 

Name 

Source 

Contents 

SRCHRD 

TWO 

Radius  of  effects  of  blast. 

MEDSR1 

TWO 

Middle  radius  of  effects. 

SMLSR1 

TWO 

Small  radius  of  effects. 

XCNT 

TWO 

X  coordinate  of  ground  zero. 

YCNT 

TWO 

Y  coordinate  of  ground  zero. 

RECNUM 

TWO 

Record  number  of  barrier  to  be  updated 

IHOB 

TWO 

Height  of  burst. 

c. 

Output  Variables: 

Name 

Destination 

Contents 

10  F 

DF2 

Radiological  barriers  description. 

d. 

zero  of 

Processing  Description, 
the  blast,  routine  NUCSCH 

Passed  the  radius  of  effects  and  ground 
determines  all  barriers  intersected  by 

blast  area.  A  four-sided  barrier  is  constructed  and  placed  on  the  barrier 
file.  Another  entry  to  this  routine  decreases  the  size  of  radiological 
barriers  due  to  time  decay.  The  current  four-sided  barrier  is  removed  and 
replaced  by  a  new  one  of  smaller  diameter. 
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ENGINEER  MODEL  OUTPUT  DESCRIPTIONS 


1.  INTRODUCTION.  This  appendix  contains  detailed  descriptions  of  the  printed 
output  within  the  Engineer  Model  of  the  Period  Processor.  Figure  IV-14-C-1 
depicts  the  format  of  the  printout.  In  the  figure  an  alphabetical  character 
(descriptor)  designates  an  appropriate  line,  group  of  lines,  or  column  that 
is  explained  as  follows. 


Output 

Descriptor 

A 


B 


C 


Explanation 

If  the  DSL  for  any  period  contains  orders  for  engineer  tasks, 
entry  is  made  to  the  Engineer  Model  at  TCLOCK  «*  0  designated 
by  the  second  number  in  the  first  line.  During  the  first 
pass  through — for  the  first  task — the  brigade/regiment  bound¬ 
aries  are  calculated.  The  3001  print  gives  the  number  of 
Blue  brigades  first  and  then  the  number  of  Red  regiments  on 
the  first  line  as  determined  by  ZONES,  The  3040  print  shows 
the  lower  Y-intercept  boundary  on  the  left  and  the  brigade 
unit  identification  record  number  on  the  right  for  Blue 
first  and  then  the  regiment  unit  identification  record 
number  for  Red  on  the  right.  The  last  brigade /regiment  lists 
its  upper  boundary  beneath  its  lower  boundary.  These  prints 
occur  in  routines  CREA16  and  GEOM. 

Also  at  TCLOCK  =  0,  all  DSL  tasks  get  a  BUID  print  giving  the 
mnemonic  of  the  barrier  and  record  number  on  data  file  2 
containing  this  task.  The  8000  print  gives  the  engineer 
operation  code,  the  begin/complete  code,  the  eight-character 
code  identifying  the  status  of  the  barrier,  the  record  number, 
the  DSL  given  priority,  the  time  to  either  begin  or  complete 
the  task  based  on  the  be gin /complete  code,  and  whether  the 
task  is  mandatory  or  desired. 

After  all  tasks  have  been  initially  examined  with  each  given 
a  data  file  18  record,  entry  is  made  at  TCLOCK  *  1  to  begin 
ranking  priority  tasks  and  allocating  troops  and  equipment 
based  on  the  assigned  priority.  When  control  transfers  to 
routine  EPRI0R,  two  lines  of  output  occur  for  each  DSL  task. 

The  first  print  gives  the  record  on  data  file  18  initially 
associated  with  this  task  following  J  ■,  then  gives  the  six 
words  contained  on  this  record  for  the  task:  word  one  contains 
the  task  priority  soon  to  be  assigned;  word  two  is  the  record 
number  of  this  task  on  data  file  2;  word  three  is  the  force 
to  execute  the  task;  word  four  is  the  immediacy  of  the  task, 
also  to  be  assigned;  word  five  is  the  DSL  provided  time  for 
the  task;  and  word  six  is  the  mandatory  or  desired  status  of 
the  task.  The  2005  print  identifies  the  barrier  mnemonic, 
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Output 

Descriptor 


Explanation 


the  task  and  troop  type  packed  into  one  word  following  IDNT 
and  the  pass  through  the  loop.  After  entering  routine  IRECN1 
(prints  are  defined  in  the  following  paragraph),  routine 
PRORTY  generates  the  RTY  print  giving  the  traf ficability 
index,  the  task  type,  the  data  file  17  record  associated  with 
this  task,  and  the  standard  number  of  personnel  associated 
with  a  unit  of  this  troop  type. 

Routine  IRECN1  returns  the  data  from  data  file  17  for  this 
task.  The  7001  print  gives  the  data  file  17  record  number, 
the  word  on  the  record  containing  the  standard  number  of 
troops,  the  number  of  times  larger  this  task  is  than  the 
basic  size,  tne  task  type,  the  number  of  minefield  densities 
played,  and  the  basic  task  size.  The  7012  print  gives  the 
standard  rate  and  the  number  of  troops  required  for  the  task. 

After  priorities  have  been  assigned,  routine  EFEAS1  prints 
the  brigade /regiment  responsible  for  tasking  with  the  BDGE 
print,  and  calls  routine  MPRALC  which  prints  the  BRDE  print 
which  gives  the  brigade  examined  for  tasking.  The  8302  print 
gives  the  distance  any  unit  qualified  for  tasking  is  from 
the  task  site  and  gives  its  data  file  1  record  number  (IUID) . 
Following  that  array  of  prints,  the  units  are  ordered  by 
nearness  to  task  site  and  are  then  printed  with  the  unit 
identification  record  number  and  its  ranking  based  on  nearness 
to  the  site.  The  next  line  gives  this  unit's  unit  type 
designator.  Keyed  to  print  switch  4  is  the  ordered  array 
should  its  contents  be  desired.  Should  this  unit  pass  final 
qualification  checks,  an  ST37  print  occurs  indicating  that 
either  this  unit  or  its  subordinate  has  been  tasked.  Should 
two  or  more  ST37  prints  occur  under  one  UTD,  a  tally  of  the 
number  of  such  prints  will  indicate  the  number  of  subordinates 
tasked  from  this  unit.  When  all  available  units  have  been 
examined  or  the  required  number  of  units  are  assigned,  the 
IUIDMU  print  lists  the  mission  unit  unit  identification 
record  number,  and  any  other  unit  identification  record 
numbers  of  units  selected  for  the  task. 


After  returning  from  MPRALC  for  this  task,  routine  FESBIL  is 
called  which  allocates  the  necessary  equipment  for  the  task. 
The  MH  print  gives  the  item  code  being  considered  the  minimum 
and  standard  amounts  of  this  equipment  specified  by  constant 
data,  the  proportionality  factor,  this  item's  transportation 
item  code,  the  task  size,  the  equipment  multiplier,  and  the 
percent  of  the  task  to  be  accomplished.  The  RATIO  print 
gives  the  amount  of  unfinished  work  on  the  task,  the  amount 
of  equipment  needed  plus  a  five  percent  surplus,  and  the 
amount  of  equipment  on  hand  in  the  unit.  For  minefields 
to  be  built,  the  amount  needed  is  one-third  the  actual  amount 
required.  If  the  mission  unit  does  not  have  enough  equipment 
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Output 

Descriptor 


G 


H 

I 


J 


Explanation 

on  hand  to  accomplish  the  task,  the  HQEOH  print  appears.  This 
line  gives  the  amount  available  in  the  parent  of  each  unit, 
for  first  the  mission  unit  and  then  all  other  units  tasked. 

On  the  same  line  is  the  total  amount  of  equipment  on  hand  in 
the  two  superior  units,  the  amount  on  hand  in  the  parent's 
superior  unit,  the  amount  of  equipment  still  needed  (if 
negative)  or  unused  (if  positive) ,  the  total  equipment 
available,  and  any  contingency  provided  by  constant  data.  The 
8111  print  specifies  the  amount  of  equipment  obtained  and  the 
unit  providing  it. 

After  available  equipment  is  allocated,  the  E0H2  »  print 
gives  the  amount  of  fuel  allocated  to  the  unit,  the  added 
fuel  required  to  carry  a  full  load,  the  distance  to  be 
travelled  by  the  unit,  the  fuel  required  to  get  all  vehicles 
to  the  task  site,  the  unit  being  examined,  the  mission  unit, 
and  the  pass  through  the  loop  currently  being  processed.  This 
print  occurs  between  calls  to  the  routine  UPMASK  and  is  keyed 
to  print  switch  4. 

When  an  engineer  unit  arrives  at  a  task  site,  the  ENGR  print 
gives  the  time,  unit,  and  task  mnemonic  arrived  at. 

Should  a  second  or  successive  unit  arrive  at  a  task  site, 
routine  EUPDAT  is  called  to  process  the  amount  of  activity 
completed  before  each  successive  unit  arrived.  The  information 
in  the  7002  print  is  obtained  from  routine  MPRUPD  and  lists 
the  troop  type,  whether  the  minimum  or  standard  troop  rate 
is  used,  the  current  number  of  personnel  working  on  the  task 
(excluding  those  that  just  arrived),  and  the  standard  number 
of  personnel  associated  with  this  troop  type.  The  7003  print 
gives  the  word  on  data  file  17  corresponding  to  the  terrain 
modifier,  the  percent  effectiveness  if  hampered  by  this 
terrain,  and  the  optional  task  rate.  The  7004  print  gives 
the  new  rate  as  modified  by  terrain  and  weather  modifiers, 
the  weather  (day/night)  modifier,  and  the  terrain  modifier. 

After  giving  the  time  this  task  was  last  updated,  (TMLSUP) 
the  IK  print  lists  the  equipment  item  code  and  then  the  min¬ 
imum  and  standard  amounts  of  equipment,  the  proportionality 
factor,  and  the  transportation  item  code.  If  a  RATE  print 
occurs,  the  total  amount  of  equipment  on  hand  to  do  the  task 
is  less  than  the  second  number  printed  and  listed  in  constant 
data  as  a  rate  modifier  for  this  item  code  of  equipment.  The 
first  value  printed  on  this  line  lists  the  adjusted  rate  and 
the  last  value  is  the  multiplication  factor  for  equipment 
of  this  size  task.  The  7005  print  provides  the  manhours 
expended.  The  first  three  values  are  the  manhours  completed 
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Explanation 

to  date,  the  manhours  completed  since  the  last  update,  and 
the  total  manhours  completed  as  a  sum  of  the  first  two  values. 
The  fourth  value  is  the  total  manhours  required;  the  next 
value  is  an  approximate  number  of  fifteen  minute  cycles 
required  to  complete  the  task,  using  the  standard  task  rate; 
then,  the  number  of  manhours  remaining  to  be  completed;  and 
the  last  value  is  the  amount  of  time  from  this  update  to  the 
next  that  the  task  will  be  worked  on. 

The  3131  print  gives  the  amount  of  fuel  on  hand  in  all  units. 

The  XTEMP  print  gives  the  amount  of  the  equipment  the  item  code 
listed  in  the  7006  print  when  first  listed  less  the  amount 
used  on  the  task.  Subsequent  XTEMP  prints  give  the  amount 
of  equipment  on  hand  after  any  resupply.  The  8030  print 
gives  the  total  amount  of  this  equipment  item  in  all  of  the 
tasked  units  on  site.  The  7006  print  gives  the  equipment 
item  code,  the  multiplication  factor,  and  the  amount  of  the 
equipment  item  still  needed,  (if  positive)  to  be  at  standard 
strength  for  the  next  fifteen  minute  period  or  (if  negative) , 
the  amount  still  available  on  site  after  next  standard  update. 
The  fourth  value  is  the  amount  of  equipment  still  needed 
to  reach  a  proportioned  standard  strength  based  on  the  amount 
of  the  task  to  be  completed.  Then  listed  is  the  standard 
amount  of  equipment  required  to  complete  the  task  as  given  in 
constant  data.  The  last  value  on  this  line  is  the  standard  task 
rate  before  modification.  The  TEMP  print  lists  the  accumulative 
amount  of  the  equipment  item  code  obtained  in  each  of  the 
four  possible  passes  through  the  equipment  resupply  routines 
EQPT  and  EQPTUP  in  the  first  field  and  the  amount  obtained 
from  each  pass  in  the  last  field. 

Regular  engineer  updates  occur  every  15  minutes  after  one 
centiminute  into  the  period.  For  regular  updates  the  model 
returns  to  routine  EFEASI  in  an  attempt  to  allocate  any  addi¬ 
tional  troop  units  that  have  become  available  since  the 
previous  update.  All  print  statements  in  the  group  have  been 
described  previously. 

Should  a  maneuver  unit  ecounter  a  barrier  while  moving,  and 
be  unable  to  bypass  that  barrier  within  the  limits  implied 
by  its  dimensions,  the  Movement  Model  generates  an  engineer 
request  as  indicated  by  the  ENGR  MOB  REQUEST  statement. 

Should  this  occur,  or  a  conditioned  DSL  order  become  true, 
print  blocks  B  and  C  occur  sequentially  without  any  game 
time  delay  as  observed  for  DSL  tasks. 

When  a  task  is  completed,  as  noticed  by  equal  values  three 
and  four  of  the  7005  print,  a  4996  print  occurs  in  the  middle 
of  the  page  from  routine  ERELEA.  This  print  occurs  for  each 
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unit  released  from  activity  on  this  task  and  given  a  movement 
order  to  return  it  to  its  parent  unit.  Upon  return  from 
ERELEA,  the  5001  print  is  made  in  EUPDAT,  listing  the  data 
file  18  record  removed,  the  record  above  it  which  is  shifted 
downward  one  record,  and  the  last  record  on  data  file  18 
which  becomes  vacant. 

0  When  the  unit  arrives  back  at  the  location  of  its  parent, 

an  ENGR  print  specifies  that  this  is  a  return  leg  and  the 
location  of  the  unit  at  that  time.  The  ENGMDV  print  gives 
the  data  file  2  record  containing  the  information  used  by 
this  unit. 

2.  ADDITIONAL  PRINT  STATEMENTS.  Additional  print  statements  are  obtainable 
from  the  Engineer  Model.  The  routine,  print  statement,  and  reason  for  its 
appearance  are  as  follows. 

a.  Routine  PRORTY  Print  Statement: 

PRTY  TKPY  REC,  BARR 

All  tasks  that  have  been  rejected  due  to  any  error  condition  are  printed  during 
the  priorization  loop. 

b.  Routine  MPRALC  Print  Statement: 

8202 

If  a  brigade  has  any  units  of  platoon  size  subordinate  that  are  capable  of 
handling  a  particular  task,  this  print  gives  the  troop  type  and  IUIDs  of  units 
selected  this  far  for  tasking. 

c.  Routine  ENUCLE  Print  Statement: 

L TOTAL  _ 

If  a  nuclear  detonation  occurs,  LTOTAL  gives  the  beginning  record  number  of 
nuclear  nnemonics  on  data  file  2. 


8059 

Each  new  barrier  created  to  simulate  an  area  of  contamination  is  denoted  by 
the  8059  print. 

d.  Routine  NUCSCH  Print  Statement: 

5001  AL0C-  XCNT-  YCNT-  RAD- 
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This  statement  lists  the  "quadrature"  code,  X  and  Y  coordinates  of  ground 
zero  of  the  nuclear  detonation,  and  the  radius  of  effects  to  examine  for 
barriers. 


BLOC  _  IRECNM  _ 

This  statement  will  list  the  corresponding  "quadrature"  code  and  data  file  2 
record  number  for  all  barriers  with  similar  codes  to  that  listed  in  the  5001 
print.  This  information  is  obtained  directly  from  data  file  22. 

BUID  _ 

Should  a  barrier  have  a  near  identical  code  in  the  above  two  prints,  its 
mnemonic  is  printed  from  data  file  2. 

BUID  _  IRECNM _ 

Should  a  barrier  actually  lie  within  the  circle  depicting  the  radius  of 
effects,  this  print  occurs  and  signals  its  placement  in  Common  Two  for  passage 
back  to  the  nuclear  assessment  model. 
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(AVAILABLE  UNDER  SEPARATE  COVER) 


CHAPTER  15 


AIRMOBILE  MODEL 


1.  MILITARY  ACTIVITIES  REPRESENTED: 

a.  General: 

(1)  The  Airmobile  Model  permits  the  simulation  of  a  variety  of 
airmobile  operations;  however,  the  model  is  considered  to  be  primarily  an 
execution  model  as  distinguished  from  a  planning  model.  The  model  relies 
upon  the  gaming  staff  for  most  of  the  general  planning  and  decision-making 
prior  to  the  simulation  of  an  airmobile  operation,  and  these  plans  are 
implemented  through  a  set  of  gamer  orders.  The  model  may,  however,  be  used 
for  limited  planning  purposes. 

(2)  The  principal  military  activities  represented  by  the  Airmobile 
Model  include  limited  planning  based  on  gamer  input,  staging  and  loading 

of  the  airmobile  task  force,  air  movement  to  and  from  the  objective  area, 
attrition  of  the  airmobile  column  in  flight,  suppression  of  enemy  air  defenses 
by  escort  helicopters,  refueling  and  rearming  of  aircraft,  release  of  air¬ 
craft  upon  completion  of  mission,  and  the  return  of  the  aircraft  to  the  bases 
for  reassignment.  These  activities  are  discussed  in  detail  in  this  chapter. 
Other  activities  inherent  to  airmobile  operations  which  are  not  discussed 
herein  are  simulated  by  other  models.  Examples  of  such  related  activities 
are  flight  reconnaissance  (simulated  by  the  Intelligence  and  Control  Model) , 
delivery  of  preparatory  fires  (simulated  by  the  Area  Fire  and  Air  Ground 
Engagement  Models),  employment  of  the  airmobile  task  force  at  the  objective 
(simulated  by  the  Ground  Combat  Model) ,  and  resupply  of  the  task  force  (simu¬ 
lated  by  the  Combat  Service  Support  Model).  The  model  will  simulate  execution 
of  the  gamer's  plan  as  ordered  by  DSL  but  will  not  make  decisions  changing 
that  plan  to  reflect  new  information  or  enemy  responses.  Conditionals  keyed 
to  other  activities  may  be  specified.  If  resources  to  execute  the  airmobile 
operation  become  inadequate  through  either  attrition  or  consumption  during 
the  operation,  the  model  will  halt  the  simulation. 

b.  Planning.  Most  of  the  planning,  coordination,  and  preliminary 
activities  for  an  airmobile  operation  are  performed  by  the  gamers.  Informa¬ 
tion  upon  which  to  base  this  planning  is  available  at  the  start  of  the  game 
from  the  Game  Directive  and  the  Game  Plan.  Additionally,  the  information 
upon  which  to  base  this  planning  may  be  obtained  prior  to  the  start  of  a  period 
from  the  Force  Status  and  the  Intelligence  Reports  from  the  preceding  game 
period.  With  information  available,  the  gamers  execute  the  following  activities 
prior  to  simulation  of  the  airmobile  operation. 

(1)  Designate  the  Airmobile  Task  Force.  The  required  composition 
of  the  task  force  to  be  lifted  is  determined  by  the  gamers.  The  task  force 
is  composed  of  basic  units  defined  in  the  TOE  data  load  which  do  not  contain 
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equipment  items  incapable  of  being  airlifted.  The  task  force  for  a  given 
airmobile  operation  may  be  separated  into  smaller  resolution  forces  to  permit 
the  use  of  multiple  landing  zones,  staging  areas,  pickup  zones,  flight 
corridors,  lift  forces,  or  sequential  arrival  times.  Each  resolution  force 
will  be  treated  individually  within  the  model. 

(2)  Select  the  Objectives  and  Designate  the  Landing  Zone.  The 
objective  (or  objectives)  of  the  airmobile  operation  is  determined  by  the 
gamers.  Landing  zones  are  designated  by  coordinates  for  each  resolution 
force.  Intermediate  landing  zones  may  be  designated  in  addition  to  the  final 
landing  zone  if  a  series  of  lift  operations  is  desired. 

(3)  Establish  Airmobile  Lift  Timing.  The  time  for  each  lift  operation 
is  to  be  designated.  Either  the  time  to  arrive  at  the  landing  zone  or  the 
time  to  begin  the  move  may  be  specified  by  the  gamers.  The  other  times  are 
calculated  within  the  model. 

(4)  Select  Staging  Areas  and  Pickup  Points.  Staging  areas  or  pickup 
points  are  determined  for  each  resolution  force.  These  locations  are  de¬ 
scribed  by  coordinates. 

(5)  Select  Flight  Corridor.  The  flight  path  for  each  lift  operation 
is  to  be  described  by  the  coordinates  of  the  starting  and  ending  points 
(pickup  and  landing  zones)  and  up  to  three  intermediate  coordinate  locations. 
The  model  will  route  the  resolution  airmobile  force  from  the  starting  coor- 
inates  over  each  intermediate  point  to  the  ending  coordinates. 

(6)  Designate  Forward  Refueling  and  Rearming  Areas.  Adequate 
facilities  must  be  provided  to  refuel  transport  and  escort  aircraft  and  to 
rearm  escort  aircraft  within  the  forward  area.  This  is  accomplished  auto¬ 
matically  within  the  model  if  forward  refueling  and  rearming  units  are 
defined  by  the  pregame  data  load  and  are  positioned  in  the  proper  areas 
during  the  game  by  gamer  orders. 

(7)  Specify  Transport  and  Escort  Aircraft  Mix.  Up  to  10  unique 
mixes  of  transport  and/or  escort  aircraft  types,  escort  aircraft  munition 
loads,  aircraft  fuel  loads,  and  aircraft  crew  can  be  defined  for  each  force 
(Red, Blue) in  the  pregame  data  load.  The  optimal  mix  for  transporting  each 
resolution  force  within  the  airmobile  task  force  is  determined  by  the  gamers. 

(8)  Develop  the  Fire  Support  Plan.  Preparatory  fire  support  is 
planned  prior  to  the  airmobile  operation.  Artillery,  missiles,  attack  heli¬ 
copter,  and  close  air  support  may  be  utilized.  The  fire  missions  will  be 
ordered  by  the  gamers  and  simulated  by  the  Area  Fire  and  Air  Ground  Engagement 
Models. 


(9)  Designate  Lift  Force.  The  preferred  aviation  units  to  provide 
the  airlift  and  escort  resources  are  designated.  Those  units  are  directed 
by  DSL  orders  to  provide  direct  support  to  the  airmobile  task  force.  The 
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model  will  attempt  first  to  allocate  required  resources  from  units  in  direct 
support  of  the  airmobile  task  force  before  selecting  other  units.  The  gamers 
should  ensure  that  adequate  resources  (aircraft,  crews,  munitions,  and  fuel) 

,  are  available  within  the  force  and,  preferably,  at  the  unit  designated  to 
support  the  operation. 

(10)  Determine  the  Number  of  Aircraft  or  Trips.  The  number  of 
transport  aircraft  of  the  type  specified  by  the  selected  mix  is  determined. 

The  number  may  be  specified  explicitly  by  gamer  orders  or  implicitly  from 
the  desired  number  of  trips  which  may  alternatively  be  stated  in  the  gamer 

*  orders.  If  the  number  of  trips  is  specified,  the  model  will  calculate  the 
number  of  aircraft  which  would  be  required  to  transport  the  resolution  force 
utilizing  the  weight,  volume,  and  capacity  data  contained  on  the  CSS  data 
file.  The  number  of  escort  aircraft  of  the  type  specified  by  the  selected 
mix  is  determined  by  the  gamers  if  escorts  are  required. 

(11)  Prepare  Gamer  Orders.  The  set  of  gamer  (DSL)  orders  required 
to  implement  the  plan  is  then  prepared.  The  orders  are  described  in  subse¬ 
quent  sections  of  this  chapter. 

c.  Staging.  The  three  steps  of  the  staging  phase  are  described  below. 

(1)  Assembling  the  Task  Force.  The  assembling  and  organizing  of 
the  airmobile  task  force  is  under  gamer  control,  through  the  use  of  con¬ 
ventional  DSL  orders.  All  elements  of  the  force  are  ordered  to  one  or  more 
staging  areas  or  pickup  points  by  means  of  MOVE  orders.  Elements  of  the 
force  may-  be  combined  or  separated  as  desired  by  use  of  the  JOIN  and  DETACH 
orders.  The  elements  must  be  composed  of  basic  units  defined  in  the  task 
organization  and  with  a  unit  type  designator  (UTD)  in  the  TOE  load.  Elements 
are  combined  into  a  single  task  force  unit  or  into  individual  resolution 
airmobile  task  force  units  as  desired.  The  task  force  should  contain  only 
equipment  which  can  be  airlifted.  The  task  force  may  not  contain  organic 
aircraft.  The  execution  of  the  JOIN  and  DETACH  orders  is  performed  external 
to  the  Airmobile  Model  in  the  same  manner  as  any  other  order  of  that  type. 

(2)  Allocating  Lift  Resources: 

(a)  ACCEPT  TRANSPORT  Order.  To  accomplish  airlift  of  a  ground 
combat  element  one  of  two  alternative  forms  of  a  DSL  ACCEPT  TRANSPORT  order  is 
employed.  The  first  alternative  form  is: 

ACCEPT  TRANSPORT  MIX  _ ,  NUMBER  OF  AIRCRAFT  _ , 

(  NUMBER  OF  ESCORTS  _ ,  AT  TIME  _ . 

The  second  alternative  form  is: 

* 

ACCEPT  TRANSPORT  MIX  _ ,  NUMBER  OF  TRIPS  _ , 

NUMBER  OF  ESCORTS  _ ,  AT  TIME  _ . 

t 

I. 

\r 

•i 
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1_.  The  number  of  aircraft  in  the  first  alternative  refers  to 
transport  aircraft.  The  transport  mix  refers  to  the  index  number  in  the  table 
of  up  to  10  mixes  per  force  provided  in  the  constant  data  load.  Each  mix 
is  defined  in  terms  of: 

.  Transport  aircraft  type 

.  Fuel  load  per  transport  aircraft 

.  Crew  per  transport  aircraft 

.  Escort  aircraft  type 

.  Fuel  load  per  escort  aircraft 

.  Crew  per  escort  aircraft 

.  Up  to  three  escort  munition  types, 

with  quantities  per  escort  aircraft. 

2.  The  AT  TIME  _  and  NUMBER  OF  ESCORTS _ modifiers  are 

optional.  If  no  escorts  are  required,  that  modifier  clause  is  omitted.  If 
the  indicated  mix  includes  escort  aircraft  descriptions,  but  escorts  are  not 
requested  in  the  ACCEPT  TRANSPORT  order,  the  escort  aircraft  portion  of  the 
mix  description  is  disregarded.  The  AT  TIME  modifier  causes  the  aircraft  to 
arrive  and  land  at  the  pickup  zone  at  the  time  specified  if  the  aircraft  are 
capable  of  flying  from  their  bases  to  that  point  in  the  allocated  time.  If 
no  time  is  specified  or  the  specified  time  cannot  be  met,  the  aircraft  will 
arrive  at  the  pickup  zone  as  soon  as  they  are  capable  of  flying  that  distance. 

3_.  If  the  second  alternative  is  used,  specifying  the  number  of 
trips  instead  of  the  number  of  aircraft,  the  model  calculates  the  required 
number  of  aircraft,  based  on  the  lift  capacity  of  the  transport  aircraft  and 
the  weight  and  volume  of  the  personnel  and  all  equipment  in  the  unit  to  be 
lifted,  at  the  time  the  ACCEPT  TRANSPORT  order  is  initiated,  using  Combat 
Service  Support  Model  constant  data  input.  The  model  does  not  attempt  to 
allow  for  attrition  when  calculating  the  required  number  of  aircraft. 

(b)  Order  Execution: 

1_.  The  model  executes  the  order  by  first  selecting  the 
optimal  source  of  both  transport  and  escort  aircraft.  It  initially  attempts 
to  locate  an  airbase  which  can  satisfy  the  requirements  for  both  transport 
and  escort  aircraft  with  their  associated  resources.  Aircraft  are  obtained 
from  the  nearest  friendly  airbase  containing  needed  resources,  according  to 
the  designated  support  relationship  of  the  airbase  to  the  unit  to  be  lifted. 
Support  categories  are  chosen  in  the  following  order  of  preference: 

.  Direct  support  to  the  airmobile  task  force 
or  any  superior  unit 

.  General  support 

.  Direct  support  to  other  units. 
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_2.  If  a  single  base  cannot  supply  all  resources,  then  the 
model  searches  for  an  optimal  source  of  each  type  separately  (i.e.,  transport 
separate  from  escort).  An  airbase  will  not  be  selected  as  a  source  of  escorts, 
transports,  or  both  unless  it  can  provide  the  full  quantity  of  aircraft,  fuel, 
crew,  and  munitions.  If  the  model  is  unable  to  allocate  the  required  resources, 
the  period  is  terminated.  If  the  escort  aircraft  are  from  a  different  base 
than  the  transports,  the  model  simulates  the  flight  of  the  escort  aircraft 
directly  to  the  selected  transport  base  where  the  two  aircraft  units  are 
consolidated.  The  aircraft  unit  flies  from  the  transport  airbase  directly 
to  the  location  of  the  unit  receiving  the  ACCEPT  TRANSPORT  order.  Fuel  is 
consumed  by  the  aircraft  while  flying  from  the  bases  to  the  pickup  zone. 

(c)  Penetration  Flights.  If  the  consolidated  air  unit  must  pene¬ 
trate  enemy  airspace  to  reach  the  pickup  zone,  the  flight  is  routed  first  to  a 
safe  point  as  defined  by  the  Air  Ground  Engagement  Model  (Chapter  10  of  this 
section).  It  is  then  passed  to  the  in-flight  attrition  segment  which  simulates 
the  flight  from  safe  point  to  the  pickup  zone  while  being  attrited  by  air  de¬ 
fense  fire.  A  penetration  flight  is  defined  as  one  in  which  the  pickup  zone 
lies  across  a  line  perpendicular  to  the  battlefield  slope  and  passing  along 
the  forward  edge  of  the  most  forward  enemy  front  line  maneuver  battalion. 

(3)  Forming  Airmobile  Task  Force  and  Lift  Resources.  The  model 
automatically  joins  the  aircraft  unit  into  the  unit  receiving  the  ACCEPT 
TRANSPORT  order.  The  aircraft,  crews,  fuel,  and  munitions  remain  with  that 
unit  until  released  by  gamer  orders.  They  are  attrited  by  area  fire  and  air 
attacks  along  with  the  remainder  of  the  unit.  A  unit  cannot  have  more  than 
one  ACCEPT  TRANSPORT  order  active  at  any  time.  It  must  release  previously 
assigned  transport  before  accepting  any  additional  transport  resources. 

d.  Loading  and  Air  Movement.  Loading  and  air  movement  of  the  airmobile 
task  force  or  of  each  resolution  airmobile  force  (if  smaller  units  are 
assembled)  is  conducted  according  to  the  air  movement  plan,  as  expressed  by 
gamer  prepared  DSL  orders  of  the  form: 


AIRMOBILE  ASSAULT  TO  X^  -  Y^,  X2  -  Y2,  X3  -  Y3,  XA  -  Y4,  AT  TIME  ^ _ . 

The  AT  TIME  modifier  is  optional.  The  airmobile  element  to  be  lifted  must 
have  been  previously  allocated  aircraft,  by  an  ACCEPT  TRANSPORT  order  as 
described  in  the  preceding  paragraph.  This  DSL  order  causes  the  transport 
aircraft  to  be  loaded  to  their  maximum  capacities  and  with  the  escorts,  if 
any,  to  fly  from  the  current  location  of  the  element  receiving  the  order 
to  the  last  coordinate  listed  in  the  order,  traveling  over  each  listed 
intermediate  coordinate.  Up  to  three  intermediate  coordinate  points  may  be 
specified  in  addition  to  the  landing  zone  coordinates.  The  time,  if  specified, 
is  the  intended  landing  time  of  the  first  element.  If  additional  lift  trips 
are  needed,  the  aircraft  return  as  a  unit  along  the  same  flight  path  for 
additional  trips.  Aircraft  are  subject  to  possible  attrition  by  the  in-flight 
attrition  segment  on  each  flight  leg.  If  aircraft  are  lost  en  route,  priority 
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cargoes  (pregame  input)  are  loaded  first,  and  additional  trips  are  scheduled 
in  subsequent  flight  legs.  Aircraft  units  are  sent  for  refueling  and  rearm¬ 
ing  between  trips  if  the  remaining  fuel  is  insufficient  for  one  more  round 
trip  plus  30  minutes  to  spare,  or  if  the  quantity  of  air  munitions  of  any 
type  is  less  than  50  percent  of  initial  load.  On  landing,  the  lifted  element 
is  unloaded.  If  more  than  one  lift  is  involved  for  any  element,  between 
unloading  of  the  first  and  last  lifts,  the  unloaded  portion  of  the  force  can 
execute  any  DSL  order  except  JOIN,  DETACH,  AIRMOBILE  ASSAULT,  or  RELEASE 
TRANSPORT.  When  the  entire  element  is  unloaded  and  assembled,  this  restric¬ 
tion  ceases.  Air  movement  is  assumed  to  occur  at  nap-of-the-earth  altitude. 
Flight  speed  is  established  as  the  cruise  speed  of  the  slowest  aircraft  in 
the  flight. 

e.  Release  of  Aircraft.  Upon  completion  of  the  airlifting  of  any 
airmobile  element,  the  aircraft  assigned  to  that  task,  including  escorts,  if 
any,  may  be  released  to  return  to  their  respective  airbases  for  maintenance, 
repairs,  and  reassignment.  If  not  released,  the  aircraft  remain  on  the  ground 
with  the  lifted  unit  and  can  be  used  for  subsequent  air  movement.  The  release 
of  air  transport  may  be  accomplished  by  a  gamer  DSL  order  of  the  form: 

RELEASE  TRANSPORT. 

This  order  must  be  provided  to  a  unit  which  previously  received  an  ACCEPT 
TRANSPORT  order.  This  order  will  cause  the  model  to  remove  previously 
accepted  aircraft  with  their  crews,  fuel,  and  munitions  from  the  unit.  A 
new  unit  is  formed  containing  those  elements.  The  model  then  simulates  the 
flight  of  that  unit  back  to  the  airbase  or  airbases  from  which  the  aircraft 
came.  If  the  unit  is  in  enemy  airspace,  as  defined  in  paragraph  c(2)(c) 
above,  the  first  leg  of  the  returning  flight  path  is  flown  from  the  starting 
point  to  the  safe  point  as  described  in  the  Air  Ground  Engagement  Model  (Chap¬ 
ter  10  of  this  section).  Upon  reaching  the  safe  point,  a  check  is  made  to 
see  if  sufficient  fuel  is  on  board  to  return  to  the  airbase  of  the  transport 
aircraft.  If  fuel  is  needed,  the  unit  is  passed  to  the  control  of  the  forward 
area  refuel  and  rearm  segment  for  refueling  prior  to  returning  to  the  base. 
Otherwise,  the  flight  returns  directly  to  the  transport  base.  If  the  escort 
aircraft  came  from  a  different  base,  they  continue  to  their  base  of  origin. 
Aircraft  are  restored  into  the  resources  of  their  airbase  after  appropriate 
time  delays,  including  times  for  repairs  according  to  damage  categories.  Those 
delay  times  and  their  application  are  described  in  Chapter  10  of  this  section. 

f.  Refueling  and  Rearming.  When  refueling  or  rearming  of  a  unit  of 
aircraft  is  required,  the  refueling  and  rearming  segment  takes  over  control 
of  the  unit.  It  selects  the  nearest  forward  area  refuel  and  rearm  (FARR) 
area  in  the  highest  support  category  which  is  neither  moving  nor  under  attack. 
The  support  categories  are  those  listed  in  paragraph  c(2)(b)  above.  The  model 
simulates  the  flight  of  the  aircraft  as  a  unit  to  the  selected  point.  The 
unit  may  then  be  held  in  a  queue  until  service  capacity  is  available.  Service 
is  on  a  first-come  first-served  basis.  When  capacity  is  available,  the  unit 
lands  at  the  FARR  area.  Time  for  refueling  and  rearming  then  depends  on  the 
requirements  of  the  aircraft  and  the  available  capacity  of  the  facility. 


The  aircraft  within  the  unit  are  serviced  individually,  first  refueled  and 
then  rearmed  if  necessary.  If  the  capacity  is  being  fully  utilized,  the 
individual  aircraft  will  remain  in  a  refueling  queue  and  then  a  rearming  queue 
until  their  appropriate  turns  to  be  servied.  The  number  of  refuel  and  rearm 
points  at  each  FARR  area  is  predetermined  by  the  TOE  constant  data  load. 

Each  FARR  area  must  be  a  resolution  unit  composed  of  TOE  defined  basic  units. 

The  support  relationships  are  declared  in  the  task  organization  but  may  be 
altered  by  DSL  orders.  The  service  rates  of  the  rearming  points  are  specified  in 
the  constant  data  load.  After  all  aircraft  have  been  serviced  the  aircraft 
unit  is  flown  to  a  location  designated  by  the  segment  processing  the  unit’s 
current  order,  and  the  unit  is  then  returned  to  the  control  of  that  segment. 

g.  In-flight  Attrition.  Whenever  an  airmobile  flight  enters  hostile 
air  space,  the  flight  is  subject  to  possible  attrition  by  enemy  air  defense 
weapons.  This  attrition  is  simulated  within  the  model  by  considering  the 
flight  path  in  relatively  short  segments.  Only  currently  undestroyed  and 
unsuppressed  air  defense  weapons  within  range  and  having  line  of  sight  to 

a  flight  segment  are  able  to  cause  attrition  on  that  flight  segment.  Line 
of  sight  is  determined  from  flight  altitude  and  terrain  masking  at  the  weapon, 
as  calculated  from  terrain  elevation  input  data.  Flight  altitude  varies 
linearly  from  a  nap-of-the-earth  elevation  over  the  terrain  at  the  ends  of 
the  flight  leg.  When  the  flight  first  enters  range  and  line  of  sight  of  the 
first  enemy  air  defense  capable  unit  (ADCU),  a  delay  is  imposed  for  probable 
time  for  the  ADCU  to  detect  the  flight.  Delays  are  also  imposed  for  weapon 
reaction,  and  for  the  time  of  flight  of  any  projectiles  that  are  fired  at  the 
flight.  Detailed  weapon  characteristics  are  used  to  determine  whether  the 
AD  gun  or  missile  can  fire  and  how  many  projectiles  will  be  fired.  For  pro¬ 
jectiles  to  intercept  the  flight,  the  flight  must  remain  in  range  and  line  of 
sight  throughout  that  time.  Only  the  effects  of  projectiles  that  can  inter¬ 
cept  the  flight  are  considered  for  attrition.  Aiming  error  and  round-to-round 
dispersion  are  based  on  slant  range  to  the  midpoint  of  the  flight  segment  and 
are  used  to  determine  hit  probability  on  presented  area  of  the  aircraft  at  the 
aspect  angle  to  the  midpoint.  Kill  probabilities  are  determined  by  considering 
the  aircraft  vulnerable  area,  at  the  midpoint  aspect  angle,  for  the  velocity 
of  the  AD  projectile  impacting.  Good  communications  are  assumed  to  exist 
between  all  air  defense  weapons  within  a  given  ADCU,  so  that  time  delays  are 
not  reimposed  unrealistically.  Communications  are  also  assumed  between 
different  ADCUs,  again  to  prevent  unrealisti  .  reimposition  of  detection  times. 
When  the  flight  enters  range  or  line  of  sight  of  a  second  ADCU  while  a  first 
ADCU  is  still  firing  no  detection  delay  is  assessed,  although  other  delays 
may  be  assessed  as  described  in  paragraph  3e.  Weapons  within  an  ADCU  are 
considered  to  be  located  near  the  perimenter  of  the  unit  for  range  determina¬ 
tions.  No  changes  in  the  flight  path  are  automatically  made  to  evade  air 
defense  fires. 

h.  Air  Defense  Weapon  Suppression.  The  employment  of  escort  aircraft 
to  suppress  ADCUs  which  attempt  to  engage  the  airmobile  column  is  simulated 
by  the  in-flight  attrition  submodel.  Additionally,  air  defense  weapons  are 
suppressed  by  artillery,  TACAIR,  and  other  attack  helicopters  resulting  from 


the  effects  of  the  Area  Fire  and  Air  Ground  Engagement  Models.  The  in-flight 
attrition  submodel,  in  connection  with  the  Suppression  Model,  simulates  the 
suppressive  effects  of  such  fires.  The  suppressive  effects  against  an  ADCU 
are  reflected  in  the  ability  of  that  ADCU  to  attrite  the  airmobile  column  and 
are  simulated  by  means  of  a  suppression  duration  time  applied  for  each  attack 
of  an  ADCU.  The  suppression  duration  delay  times  are  specified  in  the  con¬ 
stant  data  input  for  the  Suppression  Model.  Escorts  are  assumed  to  remain 
close  to  the  transport  aircraft  they  are  escorting.  Escorts  are  not  permitted 
to  divert  more  than  a  fixed  distance  from  the  flight  path  centerline  in  order 
to  attack  an  ADCU.  That  distance  is  specified  in  the  Airmobile  Model  constant 
data  input.  If  the  ADCU  is  destroyed  or  suppressed,  it  is  assumed  not  to  be 
firing  and  is  not  subject  to  further  attack  by  escort  aircraft.  If  the  air¬ 
mobile  flight  being  escorted  has  passed  beyond  the  point  on  its  flight  path 
nearest  to  the  center  of  the  ADCU,  the  ADCU  is  not  engaged  by  escorts.  The 
model  accounts  for  the  escorts  engaging  ADCUs  at  all  times.  If  all  escorts 
to  an  element  are  currently  engaging  targets,  any  additional  ADCUs  cannot  be 
attacked  by  escorts.  If  escorts  are  available  and  the  ADCU  is  within  the 
designated  escort  divert  limit  of  the  flight  path,  escorts  are  dispatched 
in  pairs  at  the  time  the  ADCU  begins  to  fire  on  the  airmobile  element  being 
escorted.  If  an  ADCU  located  beyond  escort  divert  limit  fires  on  the  element, 
a  request  is  sent  for  quick-response  suppressive  fires  from  TACAIR  or  ground- 
based  artillery.  While  such  fires  may  not  be  delivered  in  time  to  benefit 
this  flight,  they  may  benefit  any  following  flights. 

2.  DESIGN  OF  THE  AIRMOBILE  MODEL: 

a.  Approach.  A  major  objective  in  design  of  the  Airmobile  Model  is  to 
keep  the  model  as  general  as  possible,  conforming  to  basic  airmobile  doctrine 
and  current  practice  rather  than  to  specific  situational  or  type  concepts. 

This  objective  precludes  the  application  of  automatic  decision  logic  or  other 
modeling  sophistications  that  might  be  considered.  Instead,  heavy  reliance 
is  placed  upon  gaming  personnel  to  specifically  plan  and  describe  each  air¬ 
mobile  operation  through  the  use  of  DSL  orders.  Reliance  on  gamer  control 

is  necessary,  not  only  to  achieve  generality  of  the  model,  but  also  because 
doctrine  is  either  incomplete  or  highly  flexible  in  many  specific  situations. 
Furthermore,  in  a  single  game,  only  a  limited  number  of  airmobile  operations 
is  likely  to  be  performed,  and  their  anticipated  impact  on  game  results 
justifies  a  high  degree  of  gamer  control.  Another  objective  of  the  design  is 
to  restrict  modeling  to  those  aspects  considered  essential  to  realistic 
gaming  of  airmobile  operations,  on  the  grounds  that  other  features  may  be 
added  at  a  later  time,  if  found  necessary. 

b.  Constituent  Submodels.  The  Airmobile  Model  consists  of  five  submodels. 
These  submodels,  each  of  which  constitutes  an  independent  program  segment, 
are: 
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.  Accept  Transport 
.  Airmobile  Assault 
.  Release  Transport 
.  Refuel  and  Rearm 
.  In-flight  Attrition 

c.  Macroflow.  The  flow  between  submodels  is  sequential,  as  shown  in 
Figure  1V-15-1. 

d.  Connection  with  Other  DIWAG  Models.  Simulation  of  an  airmobile 
operation  requires  utilization  of  a  large  portion  of  the  overall  DIWAG 
system.  The  only  major  DIWAG  component  connected  directly  to  the  Airmobile 
Model  is  the  Intelligence  and  Control  Model.  The  Intelligence  and  Control 
Model,  in  turn,  interacts  with  the  Area  Fire  and  Air  Ground  Engagement  Models, 
causing  fire  support  to  be  automatically  applied  as  required.  Other  impor¬ 
tant  parts  of  the  DIWAG  system  necessary  to  simulation  of  an  airmobile 
operation  are  brought  into  play  by  indirect  connections,  primarily  represented 
by  coordinated  DSL  orders. 

(1)  Intelligence  and  Control  Model.  Calls  to  the  Intelligence  and 
Control  Model  are  made  by  the  Airmobile  Model  in  two  circumstances.  One 
circumstance  is  at  the  beginning  of  each  air  movement  flight  leg.  The  pur¬ 
pose  of  this  call  is  to  subject  the  flight  to  possible  acquisition  by  enemy 
air  defense  radars.  The  second  circumstance  is  when  an  ADCU  fires  at  an 
airmobile  element  from  a  location  beyond  the  escort  aircraft  divert  limit. 

In  this  case,  this  call  is  a  request  for  quick-response  fire  support  against 
this  ADCU.  If  resources  are  available,  the  result  is  response  from  either 
the  Air  Ground  Engagement  Model  (TACAIR  or  attack  helicopters)  or  the  Area 
Fire  Model  (ground-based  artillery). 

(2)  Indirect  Connections.  Coordinated  DSL  orders  are  likely  to  be 
employed  to  activate  the  Intelligence  and  Control  Model  for  preparatory  re¬ 
connaissance  flights,  the  Area  Fire  and  Air  Ground  Engagement  Models  for 
preparatory  fires,  and  the  Ground  Combat  Model  for  task  force  employment  at 
the  objective.  Data  placed  in  the  unit  status  file  of  an  ADCU  by  the  Suppres¬ 
sion  Model  (see  Chapter  11  of  this  section)  are  used  to  determine  whether 

the  ADCU  is  suppressed  by  TACAIR  or  ground-based  artillery.  Line  of  sight 
determination  for  in-flight  attrition  is  made  by  the  Environment  Submodel. 

The  Combat  Service  Support  Model  resupplies  the  airbases,  airmobile  forces, 
and  the  ADCUs.  It  replaces  destroyed  aircraft,  lost  personnel,  and  expended 
fuel  and  ammunition, 

3.  SUBMODEL  SPECIFICATIONS: 

a.  Accept  Transport  (Segment  1): 

/ 

(1)  Purpose.  The  accept  transport  segment  is  executed  in  response 
to  a  DSL  order  of  the  form  as  follows*. 
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Figure  IV-15-1.  Macroflow  of  Airmobile  Operation 


ACCEPT  TRANSPORT  MIX  _  NUMBER  OF 

AIRCRAFT  _  NUMBER  OF  ESCORTS  _ 

AT  TIME 


or: 

ACCEPT  TRANSPORT  MIX  _  NUMBER  OF 

TRIPS  _  NUMBER  OF  ESCORTS  _ 

AT  TIME  _ . 

Such  an  order  is  given  to  an  airmobile  task  force  or  to  each  of  a  group  of 
smaller  resolution  airmobile  forces  at  some  time  prior  to  its  AIRMOBILE 
ASSAULT  order.  This  segment  locates  available  aircraft  of  the  indicated 
types;  loads  them  with  the  appropriate  munition  mix,  fuel  and  crew;  and 
moves  them  to  the  pickup  zone  at  the  indicated  time.  The  aircraft  remain 
with  that  task  force  until  explicitly  released  by  a  RELEASE  TRANSPORT  order. 
The  aircraft  may  be  used  for  a  series  of  airmobile  operations. 

(2)  Operation.  The  macroflow  of  this  segment  is  shown  in  Figure 
IV- 15- 2.  The  following  steps  are  performed: 

(a)  The  DSL  order  is  converted  to  an  automatic  event  by 
routine  ARCNRL.  The  event  is  passed  to  the  Airmobile  Model  where  it 

is  channeled  to  routine  ACCPT1.  The  unit  receiving  the  ACCEPT  TRANSPORT 
order  has  thus  simulated  a  request  for  air  transport  support,  and  the  unit 
then  proceeds  to  execute  its  next  DSL  order  in  the  normal  fashion. 

(b)  Routine  ACCPT1  processes  the  request  and  schedules  the 
departure  of  the  air  units  and  their  flights  to  the  requesting  unit  in 
the  following  sequence  of  operations. 

JL.  The  mix  type  specified  in  the  DSL  order  is  an  index 
to  the  mix  table  on  the  airmobile  data  file.  That  table  is  examined  to 
determine  the  types  of  aircraft  (escort  and  transport)  and  munitions,  and 
the  quantities  of  fuel,  munitions,  and  personnel  per  aircraft. 

2.  If  the  number  of  transport  aircraft  was  not  specified 
in  the  DSL  order  it  is  computed  by  totaling  the  weight  and  volume  of  all 
personnel  in  the  requesting  unit  and  all  equipment  excluding  aircraft, 
class  IIIA  (fuel),  and  aircraft  munitions.  The  weights  and  volumes  are 
obtained  from  the  Combat  Service  Support  Model  data  file.  The  capacity 
of  the  transport  aircraft  is  also  obtained  from  that  file.  The  number  of 
transport  aircraft  is  calculated  using  the  following  formula: 

w  V 

MAX  12  ,  JL 
W  V 

Number  of  Transport  Aircraft  ■  - a - 2 -  (IV-15-1) 

N'j 
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where: 


W.. 


Nt 

The  number 
value. 


is 

is 

is 

is 

is 

of 


the  weight  of  the  unit's  equipment  and  personnel 
the  weight  capacity  of  the  transport  aircraft  type 
the  volume  of  the  unit's  equipment  and  personnel 
the  volume  capacity  of  the  transport  aircraft  type 
the  number  of  trips  requested 

transport  aircraft  is  rounded  up  to  the  next  highest  integral 


3_.  The  list  of  friendly  airbases  is  assembled  and  sorted 
into  three  categories:  direct  support  to  the  requesting  unit;  general  support; 
direct  support  to  another  unit.  The  list  is  further  sorted  within  each 
category  in  order  of  proximity  to  the  requesting  unit. 


4_.  The  list  is  searched  once  to  select  the  airbase  which 
can  supply  all  escorts,  transports,  fuel,  munitions,  and  personnel  ranking 
highest  on  the  sorted  list.  If  no  airbase  satisfies  the  requirement,  the 
list  is  searched  again  to  select  two  bases  which  can  supply  all  escort  and 
all  transport  resources,  respectively.  If  all  resources  cannot  be  found, 
a  message  is  printed;  and  the  game  period  is  terminated. 


5_.  Mission  units  are  created  at  the  base  or  bases.  These 
units  are  temporary  resolution  units  which  are  loaded  with  the  aircraft, 
crews,  fuel,  and  munitions  provided  from  each  base.  The  mission  units  have 
locations,  unit  identifications,  and  unit  type  designations  and  are  handled 
within  the  model  as  any  other  resolution  unit  with  two  exceptions:  (1) 
they  cannot  receive  DSL  orders,  and  (2)  they  occupy  no  physical  area. 

6_.  Routine  PENRAT  is  called  to  determine  if  the  flight  is 
to  penetrate  enemy  airspace.  A  penetration  will  occur  if  the  requesting 
unit  is  located  across  a  line  perpendicular  to  the  battlefield  slope  and 
passing  along  the  forward  edge  of  the  most  forward  enemy  maneuver  battalion. 

If  a  penetration  is  to  occur,  this  subroutine  also  returns  the  coordinates  of 
the  point  along  that  line  which  Is  nearest  to  the  requesting  unit.  The  flight 
path  will  be  adjusted  to  fly  over  that  point.  The  point  is  called  the  safe 
point. 


2,.  The  flight  speeds  and  fuel  consumption  rates  of  the  air¬ 
craft  are  obtained  from  the  Air  Ground  Engagement  Model  and  Movement  Model 
data  files,  respectively. 

8.  The  total  time  required  to  combine  the  two  mission  units 
(if  two  bases  have  been  selected)  and  fly  to  the  requesting  unit  is  calculated 
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based  upon  the  flight  path  distances  and  the  flights  speeds.  This  time  is 
compared  to  the  arrival  time  designated  in  the  DSL  order  to  determine  the 
time  that  the  mission  units  will  depart  the  airbases.  If  a  time  is  not 
specified  in  the  order,  the  departure  is  scheduled  to  begin  immediately. 

9^.  An  event  is  scheduled  in  the  automatic  event  table  to 
simulate  the  flight  of  the  escort  mission  unit  to  the  transport  aircraft 
base  if  two  bases  were  selected.  That  event  will  be  processed  by  routine 
ACCPT2.  The  escort  mission  unit  is  assumed  to  fly  along  a  straight  line 
from  its  base  to  the  transport  base. 

10.  The  event  to  simulate  the  flight  of  the  combined 

mission  unit  to  the  safe  point  is  scheduled  at  this  time  if  a  penetration 

is  to  occur.  The  control  will  at  that  time  be  passed  to  the  in-flight 

attrition  segment  which  will  simulate  the  flight  from  the  safe  point  to  the 
requesting  unit  and  then  return  control  to  routine  ACCPT3. 

11.  If  no  penetration  is  to  occur,  the  event  to  fly  the 
mission  unit  to  the  requesting  unit  is  scheduled  at  this  time.  Control 
goes  to  routine  ACCPT3  at  the  appropriate  game  time. 

12.  The  flight  speed  of  the  combined  unit  is  equal  to  the 
speed  of  the  transport  aircraft.  The  speeds  are  obtained  from  the  Air 
Ground  Engagement  Model  data  file  for  the  current  weather  and  light  condi¬ 
tions. 


(c)  Routine  ACCPT2  is  executed  in  response  to  an  automatic 
event  scheduled  by  routine  ACCPT1.  The  time  of  this  event  was  established 
in  ACCPT1  as  the  time  at  which  the  transport  mission  unit  and  escort  mission 
unit  are  to  be  consolidated  into  a  single  mission  unit  for  the  flight  to 
the  requesting  unit.  The  following  sequence  of  steps  occurs. 

1_.  The  location  of  the  escort  mission  unit  is  updated  to 
that  of  the  transport  airbase.  The  fuel  consumption  for  that  leg  was 
assessed  in  ACCPT1.  The  objective  point  of  the  next  flight  leg  is  set  to 
the  coordinates  of  the  requesting  unit. 

2_.  All  fuel,  aircraft,  and  personnel  in  the  transport 
mission  unit  are  added  to  the  escort  mission  unit.  The  transport  mission 
unit  is  then  eliminated. 

3,.  Routine  PENRAT  is  called  to  determine  if  a  penetration 
will  occur  while  flying  from  the  transport  base  to  the  requesting  unit.  If 
a  penetration  will  occur,  the  flight  is  rerouted  over  the  safe  point  and  an 
event  is  scheduled  for  the  arrival  of  the  flight  at  that  point.  Control 
will  then  go  to  the  in-flight  attrition  segment  to  simulate  the  flight  from 
the  safe  point  to  the  requesting  unit,  after  which  control  will  go  to  rou¬ 
tine  ACCPT3. 
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4_.  If  no  penetration  is  to  occur,  an  event  to  process  the 
arrival  of  the  mission  unit  at  this  requesting  unit  by  routine  ACCPT3  is 
scheduled  in  the  automatic  event  table. 

5_.  Fuel  consumption  for  the  next  flight  leg  is  assessed 
using  the  consumption  rates  listed  in  the  Movement  Model  constant  data  file. 

(d)  Routine  ACCPT3  processes  the  consolidation  of  the  mission 
unit  into  the  requesting  unit.  It  is  executed  in  response  to  an  event 
scheduled  by  (1)  the  in-flight  attrition  segment,  if  the  flight  involved 
a  penetration;  (2)  routine  ACCPT1,  if  there  was  no  penetration  and  all  air¬ 
craft  came  from  the  same  base;  or  (3)  routine  ACCPT2,  if  there  was  no  pene¬ 
tration  and  the  aircraft  came  from  two  different  bases.  The  following 
sequence  of  operations  is  performed. 

.1.  All  equipment  and  personnel  in  the  mission  unit  are 
transferred  to  the  requesting  unit. 

2^.  An  array  is  established  on  the  requesting  unit's  status 
file  indicating  the  types  of  aircraft  and  munitions  which  it  has  received 
and  the  identifications  of  the  airbase  or  bases  from  which  the  resources 
were  supplied.  This  array  is  used  by  the  release  segment  to  allow  the  re¬ 
sources  to  be  returned  to  the  proper  bases. 

3_.  The  mission  unit  is  dissolved  and  its  identity  is 
available  for  reuse. 

b.  Airmobile  Assault  (Segment  2): 

(1)  Purpose.  The  airmobile  assault  segment  is  executed  in  response 
to  a  DSL  order  of  the  form: 

AIRMOBILE  ASSAULT  TO _  -  _  ,  _  -  _ , 

_  -  _ _ ,  _  -  _  AT  TIME  _ . 


Such  an  order  is  given  to  an  airmobile  task  force  to  cause  it  to  be  airlifted 
over  the  coordinate  points  listed  in  the  order  and  landed  at  the  last  coor¬ 
dinate  point  in  the  list.  The  first  element  is  to  arrive  at  the  designated 
time.  Up  to  four  coordinate  points  can  be  included.  This  order  must  have 
been  preceded  at  some  time  during  the  game  by  an  ACCEPT  TRANSPORT  order  for 
that  task  force  unit.  The  task  force  unit  may  be  any  combination  of  basic 
units  which  have  been  assembled  into  a  single  unit  by  JOIN  orders. 

(2)  Operation.  The  macroflow  of  this  segment  is  shown  in  Figure 
IV-15-3.  The  following  steps  are  performed: 

(a)  The  DSL  order  is  converted  to  an  automatic  event  by 
routine  AKCNRL.  The  event  is  passed  to  the  Airmobile  Model  where  it  is 
channeled  to  routine  ASULT1.  The  unit  is  taken  out  of  the  event  cycle 
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Figure  IV-15-3.  Macroflow  of  Airmobile  Assault  -  Segment  2 


IV-15-16 


and  will  noc  perform  its  next  DSL  order  until  the  initial  element  has  reached 
the  designated  landing  zone. 

(b)  Routine  ASULT1  builds  the  initial  data  file  12  event 
description  record  and  obtains  necessary  data  from  the  appropriate  data  files, 
which  are  saved  on  the  data  file  12  record.  It  also  schedules  the  initial 
departure  event.  The  following  sequence  of  operations  is  performed. 

1_.  The  flight  path  coordinates  contained  in  the  DSL  order 
are  read  in  using  the  DSL  interface  routines,  and  the  coordinates  are  stored 
on  the  data  file  12  event  record. 

_2.  The  types  of  escort  and  transport  aircraft  which  the 
unit  has  previously  accepted  by  an  ACCEPT  TRANSPORT  order  are  stored  on  the 
data  file  12  record. 


3_.  The  fuel  consumption  rates,  flight  speeds,  and  landing 
times  are  obtained  from  the  Air  Ground  Engagement  Model  data  file  for  each 
type  of  aircraft  and  are  stored  on  the  data  file  12  record.  The  flight  speed 
is  that  designated  for  the  weather  and  light  conditions  existing  when  the 
ASULT  order  is  initiated. 

4_.  The  total  flight  time  from  the  unit's  current  location, 
over  the  designated  intermediate  points,  to  the  landing  zone  at  the  speed 
of  the  slowest  aircraft  is  added  to  the  landing  time  contained  on  the  Air 
Ground  Engagement  Model  data  file. 

5_.  The  total  time  calculated  in  paragraph  4^  above  is  compared 
to  the  desired  arrival  time  contained  in  the  DSL  order  and  the  time  of  de¬ 
parture  is  scheduled.  If  no  arrival  time  was  specified,  or  the  desired  time 
cannot  be  accomplished  due  to  the  flight  time,  the  departure  event  is  scheduled 
immediately . 


j6.  The  departure  event  is  scheduled  by  passing  a  data  file 
12  record  to  routine  ASULT2  using  the  automatic  event  sequencing  system. 

(c)  Routine  ASULT2  processes  the  loading  of  the  transport 
aircraft  and  the  departure  of  the  air  unit.  It  performs  the  following 
sequence  of  operations . 

1_.  The  total  cargo  capacity  (weight  and  volume)  of  the  unit 
is  calculated  by  multiplying  the  number  of  transport  aircraft  by  the  weight 
and  volume  capacities  of  that  aircraft  type  which  is  contained  on  the  Combat 
Service  Support  Model  constant  data  file. 

2_.  The  amount  to  move  is  calculated  by  totaling  both  the 
weight  and  volume  of  all  personnel  and  equipment  contained  in  the  unit 
excluding  aircraft,  class  IIIA,  and  air  munitions.  The  weights  and  volumes 
of  the  items  are  obtained  from  the  Combat  Service  Support  Model  constant 
data  file. 
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.3.  The  weight  and  volume  of  all  equipment  listed  on  the 
secondary  priority  equipment  list  are  totaled  in  the  same  manner. 

4_.  If  either  the  weight  or  the  volume  to  be  moved  exceeds 
the  capacity  of  the  transports,  additional  trips  will  be  required. 

5^  If  additional  trips  are  not  required,  all  equipment  and 
personnel  are  loaded  on  the  aircraft  and  an  event  is  scheduled  to  pass 
control  to  routine  ASULT3  which  controls  the  movement  of  tne  flight.  The 
following  steps  are  not  performed  when  additional  trips  a~e  not  required. 

6^  A  mission  unit  must  be  created  and  left  at  the  pickup 
zone  with  all  personnel  and  equipment  which  cannot  be  moved.  If  this  is  not 
the  first  trip,  such  a  unit  already  exists.  This  mission  unit  has  the  same 
geometry  and  location  as  the  unit  being  transported  before  the  assualt  began. 
It  can  be  assessed  by  air  and  artillery  fire  as  any  other  unit.  It  cannot 
execute  DSL  orders. 


7_.  The  aircraft  are  loaded  with  class  IIIA,  munition,  and 
crews.  The  fraction  of  the  remaining  first  priority  items  to  be  moved  on 
this  trip  is  calculated  by  the  following  formula: 


WA  V 

V  =  -  *  V  _  A 

A1  Wul  rBl  Vul 

(IV-15-2) 

F!  =  M1N  <FA1  •  FB1> 


where : 


is  the  fraction  of  the  first  priority  equipment 
to  be  moved  this  trip 

Wul  is  the  weight  of  all  first  priority  equipment 
and  personnel  in  the  unit 

is  the  weight  capacity  of  all  transport  aircraft 

Vu^  is  the  volume  of  all  first  priority  equipment 
and  personnel  in  the  unit 

VA  is  the  volume  capacity  of  all  transport  aircraft. 
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The  quantity  of  all  such  first  priority  items  loaded  on  the  aircraft  is 
prorated  by  fraction,  Fj_,  where  does  not  exceed  1.0. 

.8.  If  fraction,  F^,  exceeds  1.0,  there  is  additional 
capacity  remaining  to  move  some  of  the  second  priority  equipment.  The  amount 
loaded  is  prorated  by  fraction,  F2,  where: 


FA2 


=  MIN  (FA2,  Fb2) 


(IV-15-3) 


where: 


F2  is  the  fraction  of  second  priority  items  to  be 
moved  on  the  trip 

Wu2  is  the  weight  of  all  second  priority  equipment  in  the  unit 

WA»  is  the  remaining  weight  capacity  of  all  transport 
aircraft  after  loading  first  priority  items 

Vu2  is  the  volume  of  all  second  priority  equipment 
in  the  unit 

VA 1  is  the  remaining  volume  capacity  of  all  transport 
aircraft  after  loading  first  priority  items. 

9..  An  event  is  scheduled  to  pass  control  of  tne  flight  to 
routine  ASULT3  which  controls  the  movement  of  the  flight. 

(d)  Routine  ASULT3  controls  the  movement  of  all  airmobile 
assault  units.  It  updates  status,  assesses  fuel  consumption,  and  schedules 
the  following  event.  The  functions  performed  are  described  below. 

1_.  If  this  is  not  the  initiation  of  a  new  flight,  the  fuel 
consumption  is  calculated  for  the  previous  leg  using  the  rates  specified  on 
*  the  data  file  12  record  created  by  ASULT1.  The  fuel  is  subtracted  from  the 
unit  status  record  of  the  unit  being  moved.  The  coordinates  of  the  unit  are 
1  updated  to  the  completion  of  the  previous  flight  leg. 

2.  The  flight  leg  counter  on  the  data  file  12  record  is 
incremented  to  point  to  the  coordinates  of  the  end  point  of  the  next  flight 
leg,  and  those  coordinates  are  placed  on  the  unit's  status  record  for  use  by 
the  in-flight  attrition  segment. 
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3_.  If  the  unit  has  not  yet  arrived  at  either  the  landing 
zone  or  the  pickup  zone  (for  subsequent  trip  loads) ,  an  automatic  event  is 
scheduled  for  the  in-flight  attrition  segment.  That  segment  will  control 
the  movement  within  a  flight  leg  and  pass  control  back  to  ASULT3  when  the 
flight  leg  has  been  completed. 

j4.  If  the  unit  has  arrived  at  the  landing  zone,  an  event 
is  scheduled  which  passes  control  to  routine  ASULT4 .  The  routine  controls 
the  recomposition  of  the  unit  at  the  landing  zone. 

_5.  If  the  unit  is  at  the  pickup  zone  and  the  landing  zone 
is  in  enemy  territory,  the  routine  determines  if  refueling  or  rearming  is 
required.  If  sufficient  fuel  is  not  remaining  to  make  another  complete 
round  trip  with  30  minutes  reserve,  or  if  less  than  one  half  of  the  initial 
munition  load  remains,  refueling  and  rearming  is  performed.  The  routine 
passes  control  to  the  refuel  and  rearm  segment.  After  accomplishing  that 
operation,  the  refueled  and  rearmed  aircraft  will  be  returned  to  the  pickup 
zone,  and  control  will  return  to  routine  ASULT3. 

ji.  If  refueling  or  rearming  is  not  required,  an  event  is 
scheduled  for  control  to  go  to  routine  ASULT2,  which  loads  the  aircraft 
for  the  next  trip. 


]_.  If  the  unit  is  departing  from  a  landing  zone  in  friendly 
territory  and  returning  for  another  trip  load,  the  refuel/rearm  decision 
process  is  made  at  that  point. 

8_.  The  landing  delay  time  placed  on  the  data  file  12  record 
by  ASULT1  is  applied  to  all  flights  landing  at  both  the  pickup  and  landing 
zones . 


(e)  Routine  ASULT4  controls  the  recomposition  of  the  unit  at 
the  landing  zone.  It  responds  to  events  scheduled  by  ASULT3.  This  routine 
performs  the  following  sequence  of  operations. 

1^  If  this  is  not  the  first  trip,  all  personnel  and  equipment 
are  transferred  from  the  arriving  unit  into  the  element  of  the  unit  which  had 
previously  been  unloaded. 

2_.  If  this  is  the  first  trip,  the  unit  being  lifted  is 
updated  to  the  location  of  the  landing  zone  and  contains  all  equipment  and 
personnel  contained  in  the  first  trip. 

3.  The  routine  determines  if  the  landing  zone  is  in  enemy 
territory  by  comparing  the  location  of  the  center  of  the  landing  zone  with 
the  straight  line  FEBA  approximation  described  in  Chapter  5  of  this  section. 

If  the  landing  zone  lies  across  that  line,  the  airmobile  flag  on  the  assault¬ 
ing  unit  status  record  is  set.  This  flag  serves  two  purposes;  (1)  the  unit 
will  only  be  resupplied  by  aircraft  within  the  Combat  Service  Support  Model, 
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and  (2)  the  unit  will  not  be  used  for  future  battlefield  geometry  calculations. 
The  flag  may  be  cleared  during  the  periodic  battlefield  geometry  update  if  the 
FEBA  has  moved  beyond  the  location  of  the  center  of  the  unit  such  that  it  is 
no  longer  on  the  enemy  side  of  the  line. 

4_.  If  additional  trips  are  required  to  move  elements  of  the 
unit  remaining  at  the  pickup  zone,  a  mission  unit  is  formed  containing  the 
aircraft,  crews,  class  IIIA,  and  air  munitions  remaining  with  the  unit. 

That  mission  unit  is  returned  to  the  pickup  zone  along  the  same  flight  path 
flown  to  the  landing  zone.  An  event  is  scheduled  to  pass  control  back  to 
routine  ASULT3,  which  will  control  the  flight  of  the  mission  unit. 

_5.  After  the  last  trip  has  been  completed,  all  mission 
units  are  dissolved  and  the  entire  reconstituted  unit  remains  in  the  vicinity 
of  the  landing  zone  with  attached  aircraft  and  associated  resources. 

6^  When  the  first  trip  arrives  at  the  landing  zone,  the 
resolution  task  force  unit's  identity  arrives  with  it.  The  task  force  unit's 
location  is  updated,  and  it  begins  performing  its  subsequent  DSL  orders. 

The  width  and  depth  of  the  unit  will  be  those  appropriate  for  its  new  activity. 

c.  Release  Transport  (Segment  3): 

(1)  Purpose.  The  release  transport  segment  is  executed  in  response 
to  a  DSL  order  of  the  form: 


RELEASE  TRANSPORT. 

Such  an  order  is  given  only  to  a  unit  which  had  previously  been  given  an 
ACCEPT  TRANSPORT  order  and  provided  with  transport  support.  This  order 
allows  the  supporting  aircraft  to  return  to  their  respective  bases  for 
refueling,  rearming,  and  reassignment. 

(2)  Operation.  The  macroflow  of  this  segment  is  shown  in  Figure 
IV-15-4.  The  following  steps  are  performed. 

(a)  Routine  ARCNRL  processes  the  DSL  order.  It  creates  a  data 
file  12  event  record  and  passes  it  to  the  Airmobile  Model  where  it  is  channeled 
to  routine  RLEAS1.  The  unit  receiving  the  order  then  proceeds  to  execute  the 
next  order  in  its  DSL  order  scenario.  The  execution  of  this  order  does  not 
consume  any  game  time  from  the  unit's  planned  scenario.  It  serves  only  to 
initiate  the  process  described  in  the  following  paragraphs. 

(b)  Routine  RLEAS1  is  executed  in  response  to  the  data  file  12 
event  scheduled  by  routine  ARCNRL  lift.  Its  purpose  is  to  extract  the  air¬ 
mobile  lift  resources  from  the  u..  >  ,  create  a  mission  unit,  and  schedule  the 
events  to  return  the  aircraft  with  associated  personnel  and  equipment  to  the 
safe  point.  The  following  operations  are  performed. 
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1_.  The  flight  speeds  of  the  transport  and  escort  aircraft 
types  are  obtained  from  the  Air  Ground  Engagement  Model  data  file.  The 
speeds  pertaining  to  the  current  weather  and  light  conditions  are  selected 
and  saved  on  the  data  file  12  event  record. 

2_.  The  fuel  consumption  rates  for  both  aircraft  types  are 
obtained  from  the  Movement  Model  constant  data  file.  Those  rates  are  also 
saved  on  the  data  file  12  event  record. 

3_.  Routine  PENRAT  is  called  to  determine  if  the  return 
flight  will  require  penetration  of  enemy  air  space.  A  penetration  flight 
is  defined,  and  one  in  which  the  aircraft  are  being  released  from  a  unit 
across  the  penetration  line  is  described,  in  paragraph  3a(2)(b)  above.  If 
a  penetration  flight  is  to  occur,  this  subroutine  also  returns  the  coordinates 
of  the  point  along  that  line  nearest  the  releasing  unit.  That  point  is 
called  the  safe  point,  and  the  returning  flight  path  will  be  adjusted  to 
fly  directly  to  that  point  before  returning  to  the  base. 

4^  If  a  penetration  flight  is  to  occur,  or  if  the  transport 
and  escort  aircraft  are  from  the  same  airbase,  a  single  mission  unit  is 
created.  All  transport  and  escort  aircraft  with  their  associated  crews, 
class  IIIA,  and  munitions  are  extracted  from  the  releasing  unit  and  joined 
into  the  mission  unit. 

5_.  If  the  two  aircraft  types  are  from  different  bases,  and 
a  penetration  flight  is  not  required,  two  mission  units  are  created.  In 
this  case,  the  escort  aircraft  and  their  associated  crews,  fuel,  and  munitions 
are  joined  into  one  mission  unit  while  the  transport  aircraft  with  their 
associated  crews  and  fuel  are  joined  into  the  other. 

6,.  The  coordinates  of  the  objective  point  of  the  first 
flight  leg  are  set  for  each  mission  unit.  If  it  is  a  penetration  flight, 
these  are  the  coordinates  of  the  safe  point;  otherwise,  they  are  the  coor¬ 
dinates  of  the  escort  and  transport  aircraft  parent  bases. 

7_.  Penetration  flights  are  then  passed  to  the  in-flight 
attrition  segment  which  controls  the  movemeut  of  the  flight  from  the  releas¬ 
ing  unit  to  the  safe  point.  Upon  arriving  at  the  safe  point,  the  mission 
unit  will  be  passed  back  to  routine  RLEAS2.  The  following  steps  are  not 
performed  for  penetration  flights. 

8_.  The  distance  from  the  releasing  unit  to  the  objective 
is  calculated  and  the  time  of  flight  is  determined  using  the  flight  speeds 
of  the  aircraft. 

9_.  The  events  corresponding  to  arrival  at  the  bases  is 
scheduled  on  the  data  file  12  automatic  event  table.  That  event  will  be 
processed  by  routine  RLEAS3  at  the  appropriate  time. 


War***-  •  ■  | 
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(c)  Routine  RLEAS2  is  executed  in  response  to  an  event  scheduled 
by  the  in-flight  attrition  segment  which  indicates  that  a  released  mission 
unit  has  arrived  at  the  safe  point.  This  routine  schedules  the  return  of 
the  mission  units  to  the  appropriate  airbases.  The  following  procedure  is 
performed . 


The  distance  from  the  safe  point  to  the  transport  airbase 
is  calculated  and  the  time  to  fly  to  the  base  is  determined  using  the  trans¬ 
port  aircraft  flight  speed  saved  by  routine  RLEAS1.  The  amount  of  fuel  re¬ 
quired  for  the  return  flight  is  then  determined  using  the  transport  aircraft 
fuel  consumption  rate  saved  by  routine  RLEAS1. 

2_.  If  the  aircraft  are  to  be  returned  to  different  bases, 
a  mission  unit  is  created.  The  transport  aircraft  with  their  associated 
crews  and  fuel  are  joined  into  that  mission  unit. 

3_.  If  the  original  mission  unit  did  not  have  enough  for 
the  transport  aircraft  to  return  to  their  base,  the  unit  is  passed  to  the 
forward  area  refuel  and  rearm  segment  for  refueling,  after  which  it  will 
return  to  the  control  of  routine  RLEAS3. 

4..  The  remaining  equipment  in  the  original  mission  unit  is 
associated  with  the  escort  aircraft.  If  there  is  not  enough  fuel  left  for 
the  escorts  to  return  to  their  base,  that  unit  is  then  passed  to  the  forward 
area  refuel  and  rearm  segment,  after  which  it  will  be  returned  to  the  control 
of  routine  RLEAS3. 


5_.  The  mission  units  not  requiring  refueling  are  returned 
directly  to  their  bases.  Events  are  scheduled  on  the  data  file  12  automatic 
event  table  for  the  arrival  of  the  aircraft  back  at  their  bases.  Those 
events  will  be  processed  by  routine  RLEAS3. 

(d)  Routine  RLEAS3  is  executed  in  response  to  events  scheduled 
by  routines  RLEAS1  and  RLEAS2.  It  updates  the  mission  units  for  the  flight 
to  the  base  and  schedules  the  restoration  of  the  aircraft  for  reassignment. 
The  following  operations  are  performed. 

1_.  The  fuel,  personnel,  and  munition  present  in  the  arriving 
mission  unit  are  transferred  directly  to  the  unit  status  record  of  the  air¬ 
base  after  subtracting  fuel  consumed  on  the  return  flight. 

2_.  The  landing  times  for  the  transport  and  escort  aircraft 
types  are  obtained  from  the  Air  Ground  Engagement  Model  data  file. 

3_.  The  number  of  aircraft  receiving  B-kills  is  determined 
from  the  mission  unit's  status  file.  The  time  required  to  return  an  aircraft 
with  a  B-kill  to  service  is  obtained  from  the  Air  Ground  Engagement  Model 
data  file.  The  landing  time  is  added  to  that  time,  and  an  event  to  return 
B-killed  aircraft  to  service  is  scheduled  on  the  data  file  12  automatic  event 
table. 


4_.  The  preceding  step  is  repeated  for  aircraft  with  C-  and 
D-kills.  (A,  E,  C,  and  D-kills  are  defined  in  Chapter  10  and  in  the  descrip¬ 
tion  of  the  in-flight  attrition  segment  contained  below). 

_5.  An  event  to  return  undamaged  aircraft  to  service  after 
the  landing  time  plus  the  aircraft  availability  time  is  scheduled  on  the  data 
file  12  automatic  event  table.  The  availability  time  is  obtained  from  the 
Air  Ground  Engagement  Model  data  file. 

Mission  units  are  dissolved,  and  their  identities  may 
be  used  for  other  missions. 

(e)  Routine  RLEAS4  is  executed  in  response  to  an  event  scheduled 
by  routine  RLEAS3.  This  routine  is  called  at  the  appropriate  time  to  restore 
aircraft  into  service  after  completion  of  a  mission  and  to  record  landing  and 
availability  times.  It  increments  the  quantity  of  aircraft  on  hand  contained 
on  the  airbase'  unit  status  record. 

d.  Refuel  and  Rearm  (Segment  4): 

(1)  Purpose.  The  Forward  Area  Refuel  and  Rearm  (FARR)  submodel  is 
designed  to  simulate  the  refueling  and  rearming  of  US  Army  aircraft  performing 
airmobile  assault  operations.  The  model  is  designed  to  simulate  the  opera¬ 
tions  of  mobile  FARR  areas  during  mid-intensity  conflicts  where  there  would 
exist  a  continuing  and  frequent  requirement  for  rapid  displacement  of  the 
FARR  area.  This  mobility  is  required  to  ensure  continuous  aircraft  refueling/ 
rearming  operations  and  to  avoid  destruction  from  enemy  fire.  The  FARR 
submodel  is  based  primarily  on  the  results  of  a  US  Army  Supply  Agency  study 
and  selected  FMs  (References  1,  2,  and  3). 

(2)  Operation: 

(a)  Only  the  refueling  and  rearming  operations  are  discussed  in 
this  paragraph.  Resupply  of  fuel  and  ammunition  to  the  FARR  area  is  discussed 
in  Chapter  16,  Combat  Service  Support  Model.  When  the  FARR  area  is  in  hostile 
territory,  it  is  always  resupplied  by  unit  distribution  through  an  airlift 
operation. 


(b)  During  airmobile  operations,  a  flight  of  troop  ships  and 
their  escorts  may  be  required  to  make  several  trips  between  the  pickup  zone 
and  the  landing  zone.  A  flight,  arriving  at  the  pickup  zone,  is  sent  to 
refuel  if  either  of  two  conditions  occur.  The  first  condition  is  that  the 
escort  aircraft  (if  there  are  any)  have  expended  50  percent  of  any  type  of 
ammunition.  The  second  condition  is  that  the  aircraft  do  not  have  enough 
fuel  to  make  one  more  round  trip  to  the  landing  zone  with  30  minutes  reserve. 
All  aircraft  sent  to  the  FARR  area  are  refueled  and,  if  appropriate,  rearmed. 

(c)  Once  a  determination  has  been  made  to  send  the  flight  to 

a  FARR  area,  a  FARR  area  is  chosen.  If  the  flight  has  a  FARR  area  in  direct 
support,  it  is  sent  there.  Otherwise,  it  is  sent  to  the  nearest  general 
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support  FARR  area.  If  no  general  support  areas  are  available,  the  flight  is 
sent  to  the  nearest  FARR  area  which  is  in  direct  support  of  another  unit. 

In  the  case  where  the  selected  FARR  area  is  moving,  under  attack,  or 
does  not  have  sufficient  fuel,  an  alternative  FARR  area  is  chosen. 

(d)  Figure  IV-15-5  shows  a  schematic  of  the  refueling  and 
rearming  process  which  is  simulated.  As  shown,  refueling  and  rearming  tasks 
are  accomplished  separately,  and  both  a  refuel  queue  and  a  rearm  queue  are 
simulated.  If  no  rearming  is  required,  the  flight  leaves  the  FARR  area  as 
soon  as  all  aircraft  in  the  flight  have  been  refueled. 

(e)  Once  the  flight  arrives  at  the  FARR  area,  it  is  put  into 

a  refuel  queue.  No  flights  are  given  priority  service.  A  "first-in,  first- 
served"  rule  is  observed  at  both  the  refueling  aid  rearming  areas  to  facil¬ 
itate  the  queuing  process.  A  particular  flight  does  not  land  at  the  FARR 
area  until  service  capabilities  are  available.  If  they  are  not  available, 
the  aircraft  are  diverted  to  a  holding  area  to  await  their  turn  in  the  re¬ 
fueling  queue. 

(f)  All  aircraft  arriving  at  the  FARR  area  are  refueled.  Since 
the  Airmobile  Model  does  not  simulate  fire  by  transport  aircraft,  only  escort 
aircraft  are  considered  for  rearming.  Individual  aircraft  are  refueled  and 
then,  if  necessary,  rearmed,  in  that  sequence.  Within  a  flight,  aircraft 
which  require  rearming  are  refueled  before  aircraft  which  do  not.  All  air¬ 
craft  are  assumed  to  accept  fuel  at  50  gallons  per  minute  at  each  fuel  inlet. 

(g)  Total  refuel  service  time  for  a  set  of  aircraft,  RFTPS ,  at 
a  refuel  area  is: 


RFTPS  =  RFT  +  RFMT 


(IV-15-4) 


where : 


RFT  *  refuel  time  per  aircraft  set  (minutes) 

RFMT  *  refuel  maneuver  time  (minutes) 

(h)  The  refuel  time  per  aircraft  set  is  found  by  first  determining 
the  average  amount  of  fuel  required  per  aircraft  inlet.  The  average  fuel  amount 
is  then  divided  by  the  intake  rate  of  an  aircraft  fuel  inlet.  This  calculation 
is  expressed  by: 


RFT  (min) 


TRF  (gal) _ 

NI*RATE  (gal/min) 


(IV-15-5) 


where : 


TFR  *  total  fuel  required  by  all  aircraft  in  a 
flight  (gallons) 

NI  =  total  number  of  aircraft  fuel  inlets 

RATE  ■  assumed  rate  at  which  aircraft  can  accept 

fuel  at  an  inlet  (currently  50  gallons/minutes). 


The  number  of  inlets  is  used  rather  than  the  number  of  aircraft  in  order  to 
simulate  a  FARR  area  with  different  type  refuel  devices,  each  with  a  different 
number  of  nozzles  refueling  different  type  aircraft  with  varying  numbers  of 
fuel  inlets.  A  refuel  point  is  defined  as  containing  one  nozzle,  allowing 
the  number  of  fuel  inlets  in  the  flight  to  be  matched  with  the  refuel  points. 

(i)  A  refueling  maneuver  time  is  input  to  account  for  delays 
other  than  the  actual  refuel  time.  This  includes  the  time  required  to 
maneuver  a  single  aircraft  into  position  for  refueling  from  a  position 
approximately  200  yards  from  the  refuel  point,  time  to  insert  nozzle(s)  and 
commence  (but  not  conduct)  fueling,  time  to  remove  nozzles  and  to  maneuver 
the  aircraft  clear  of  the  refuel  point. 

(j)  As  soon  as  aircraft  are  refueled,  those  which  require 
rearming  are  maneuvered  to  a  rear m  area  where  they  are  put  in  a  rearm  queue. 
Aircraft  not  requiring  rearming  are  put  in  a  holding  area. 

(k)  All  aircraft  which  require  any  ammunition  are  rearmed. 

Rearm  time  per  aircraft  set  is  a  function  of  aircraft  and  munition  type  but 
is  considered  to  be  independent  of  munitions  consumed.  Rearm  time  per  set 
of  aircraft  is  input  as  constant  data.  The  number  of  rearm  points  at  each 
FARR  area  is  also  constant  data  and  is  input  as  a  function  of  unit  type 
designation  (UTD) .  The  number  of  points  will  be  degraded  if  the  FARR  sus¬ 
tains  loss  of  personnel. 

(l)  A  second  maneuver  time  is  input  to  account  for  the  delay 
created  in  rearming.  This  time  includes  the  time  for  an  aircraft  to  move 
from  the  rearm  queue  area  to  a  rearm  point  plus  the  time  required  for  prepar¬ 
ing  for  takeoff.  Total  service  time  for  a  set  of  aircraft  at  a  rearm  area 

is  rearm  maneuver  time  plus  rearm  time  per  set  of  aircraft.  Although  all 
aircraft  in  a  flight  remain  at  the  FARR  area  until  the  whole  flight  has  been 
processed,  the  aircraft  leave  the  service  point  immediately  on  completion  of 
servicing. 


(m)  Each  type  FARR  area  must  be  defined  as  a  basic  unit  with 
a  unique  unit  type  designation  (UTD).  The  number  and  type  of  Farr  areas 
which  are  to  be  played  are  defined  by  the  task  organization.  The  amount 
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and  type  equipment  at  each  FARR  area  is  described  in  TOE  load.  An  example  of 
what  would  be  at  a  typical  FARR  area  located  in  friendly  territory  is  shown 
below: 


.  6  refueling  systems 

.  20  500  gallon  tanks 

.  1  fuel  truck 

.  1  ammunition  truck 

.  4  rearm  points 

(n)  Since  each  refueling  system  has  two  nozzles,  the  FARR 
area  has  12  outlets  for  fuel.  Lethal  areas  are  input  for  the  500  gallon 
tanks  and  for  the  trucks.  The  amount  of  fuel  in  each  should  be  listed  as 
secondary  equipment  for  that  item  so  that  fuel  may  be  attrited  when  the  fuel 
tanks  and  trucks  are  hit  by  artillery  fire.  Lethal  areas  of  aircraft  are 
also  input  so  that  they  can  be  attrited  by  artillery  fire  while  in  the  refuel 
and  rearm  areas.  In  determining  the  number  of  FARR  areas  required,  the 
tradeoff  between  system  utilization  and  waiting  time  must  be  considered.  A 
FARR  area  should  have  enough  service  points,  personnel,  and  equipment  so 
that  a  long  waiting  line  does  not  develop.  On  the  other  hand,  the  more 
refueling  and  rearming  points  at  a  forward  area,  the  greater  the  system's 
idle  time  will  become.  Furthermore,  the  greater  the  number  of  service  points, 
the  larger  the  area  to  support  the  refueling/rearming  activities  must  be, 
causing  problems  in  clearing  and  securing. 

(o)  In  order  to  more  clearly  explain  how  the  model  simulates  the 

rearming  and  refueling  activities  at  a  FARR  area,  an  illustrative  example  is 
developed  below.  The  situation  is  shown  in  Figure  IV-15-6.  Four  flights 

simultaneously  arrive  at  a  FARR  area  at  time  t  equals  zero.  The  FARR  area 

has  10  refuel  points  and  five  rearm  points  available.  There  is  a  different 
number  of  aircraft  in  each  flight.  Note  that  the  refuel  and  rearm  service 
times  per  aircraft  may  be  different  for  different  flights.  These  times  de¬ 
pend  on  the  type  aircraft  and  their  munition  loads.  In  flight  1,  only  three 

of  a  total  of  15  aircraft  require  rearming.  The  assumption  is  that  this  flight 
consists  of  three  escort  aircraft  and  12  transport  aircraft.  The  number  of 
escort  aircraft  in  the  other  three  flights  are  four,  zero,  and  four  respec¬ 
tively.  Figure  IV-15-7  shows  the  sequence  and  times  at  which  the  four  flights 
would  be  refueled  and  rearmed  as  simulated  in  the  FARR  model. 

(p)  Since  the  rearming  of  flight  4  could  not  begin  until  time 

t  *  22  minutes,  the  flight  does  not  land  at  the  FARR  area  until  time  t  -  20 
minutes,  at  which  time  it  immediately  starts  refueling.  This  2-minute  time 
difference  allows  the  first  ten  aircraft  of  flight  4  to  complete  refueling 

at  the  time  rearm  points  in  the  rearm  queue  become  available.  In  order  to 

minimize  the  number  of  aircraft  on  the  ground  at  the  FARR  area  at  any  one 
time,  a  flight  does  not  land  at  the  FARR  area  until  it  can  start  refueling. 

The  aircraft  are  thus  vulnerable  to  artillery  fire  for  a  shorter  time  period. 
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(q)  Since  three  of  the  15  aircraft  of  flight  1  require  rearming, 
flight  1  departs  the  FARR  area  at  t  =  22  minutes.  Flight  3  does  not  require 
any  rearming;  hence,  it  is  refueled  as  soon  as  any  refueling  capability 
becomes  available  (t  =  4  minutes)  and  departs  immediately  after  refueling 

(t  =  8  minutes) .  Note  that  flight  4  does  not  leave  the  FARR  area  until 
t  =  49  minutes,  even  chough  refueling  of  all  aircraft  was  completed  at  t  =  24 
minutes,  and  only  four  aircraft  in  the  flight  required  rearming. 

(r)  As  is  illustrated  in  Figure  IV-15-7,  each  flight  arrives  at 
and  departs  from  the  FARR  area  as  a  complete  flight,  although  some  aircraft 
may  be  refueling  while  ethers  are  rearming.  Only  those  aircraft  which 
require  rearming  are  sent  to  the  rearm  queue.  Thus,  if  no  aircraft  in  a 
flight  require  rearming,  the  entire  flight  departs  the  area  as  soon  as  refuel¬ 
ing  is  completed. 

e.  In-flight  Attrition: 

(1)  General: 

(a)  Purpose.  The  In-flight  Attrition  Submodel  is  designed  to 
simulate  the  ground-to-air  attrition  incurred  by  any  aircraft  which  flies 
through  hostile  airspace.  This  submodel  is  intended  to  represent  the  principal 
determinants  of  attrition  in  sufficient  detail  to  permit  realistic  simulation 
of  airmobile  and  other  air  operations  within  the  DIVWAG  system.  Rather  than 
depend  upon  the  results  of  any  external  high-resolution  models ,  this  submodel 
is  designed  to  use,  as  input,  available  basic  data  on  air  defense  weapons 
and  aircraft. 


(b)  Capabilities.  The  In-flight  Attrition  Submodel  can  accommodate, 
for  each  force  (Red  and  Blue) ,  nine  types-*-  of  aircraft  and  15  types  of  ground- 
based  air  defense  weapons,  including  both  guns  and  missiles.  Any  resolution 
unit  which  currently  contains  any  of  the  specified  types  of  air  defense  weapons, 
is  considered  by  this  submodel  to  be  an  air  defense  capable  unit  (ADCU) . 

The  submodel  considers  the  air  defense  capability,  size,  and  location  of 
each  such  ADCU  versus  the  position  and  speed  of  the  air  unit  on  its  current 
flight  leg.  Attrition  by  ground-based  air  defense  weapons  is  restricted 
to  aircraft  and  their  contents.  Provision  exists  for  addition  of  an  air- 
to-ground  attrition  routine  at  a  later  date.  Suppression  of  air  defense 
weapons  is  simulated  in  terms  of  input  air  defense  suppression  duration 
times  applied  for  each  attack  by  escort  aircraft,  TACAIR,  or  ground-based 
artillery.  This  submodel  dispatches  a  pair  of  escorts,  if  available,  to 
attack  any  firing  ADCU  which  is  within  a  limited  distance  from  the  air  unit. 

The  submodel  requests  quick-reaction  fire  support  by  TACAIR  or  ground-based 
artillery  against  any  firing  ADCU  which  is  beyond  a  specified  distance  from 
the  flight  path.  Aircraft  attrition  calculations  for  guns  employ  aircraft 
presented  area,  weapon  accuracy,  and  aircraft  vulnerable  areas  to  each  air 
defense  weapon  type,  based  on  the  average  engagement  geometry  of  relatively 


1.  Two  types  in  any  one  flight. 
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short  segments  of  the  flight  path.  For  missiles,  accuracy  and  probability 
of  kill  versus  miss  distance  are  used.  Only  unsuppressed  ADCUs  are  permitted 
to  fire.  Terrain  masking;  weapon  limitations  of  range,  altitude,  slew  rate, 
and/or  launch  envelope;  and  delays  for  acquisition,  reaction,  and  projectile 
flight  are  considered  in  determining  whether  projectiles  can  intercept  the 
flight  on  a  particular  segment.  The  number  of  projectiles  which  can  inter¬ 
cept  on  the  segment  is  further  determined  by  number  of  unsuppressed  weapons 
currently  on  hand,  ammunition  on  hand,  and  rate-of-fire  characteristics  of 
each  weapon  type.  Degradation  for  weather  and  visibility  conditions,  elec¬ 
tronic  countermeasures  (ECM) ,  weapon  system  reliability,  and  evasive  flight 
are  included.  Aircraft  losses  are  recorded  in  four  kill  categories;  quick 
kills  (Category  A),  forced  landings  (Category  B) ,  mission  aborts  (Category  C), 
and  other  damage  (Category  D) ,  Cargo  and  troop  losses  are  proportioned  to 
total  aircraft  kills. 

(c)  Approach.  The  In-flight  Attrition  Submodel  utilizes 
extensively  the  DIVWAG  event  sequencing  system.  The  basic  approach  used  is 
to  consider  the  future  flight  path  a  leg  at  a  time;  to  start  with  a  limited 
number  of  essential  criteria;  and  to  use  them  to  identify  and  isolate,  a 
short  distance  in  advance  of  the  actual  air  unit,  portions  of  the  flight  leg 
where  air  defense  engagement  will  be  possible.  Progressively  detailed  analy¬ 
sis  is  then  applied  to  narrow  the  scope  of  consideration  and  refine  the 
level  of  information  about  anticipated  interactions  until  segments  of  the 
flight  leg  are  defined  on  which  unique  sets  of  air  defense  weapons  will 
intercept  the  air  unit.  When  the  air  unit  has  reached  the  end  of  each  such 
segment,  final  filtering  makes  use  of  up-to-date  information,  and  a  set  of 
attrition  calculations  is  employed  to  assess  fractional  aircraft  losses  over 
the  entire  segment. 

(2)  Submodel  Operation.  The  submodel  is  composed  of  three  basic 
sections.  Section  1  identifies  segments  of  the  flight  leg  where  aircraft 
attrition  is  possible.  Section  2  breaks  these  flight  leg  segments  into  sub- 
segments,  termed  constant  fire  subsegments  (CFS)  within  which  the  air  unit 
is  expected  to  be  subject  to  attrition  by  a  unique  and  constant  set  of  air 
defense  weapons.  Section  3  calculates  and  assesses  to  the  air  unit  all 
losses  incurred  on  a  CFS. 

(a)  Callers.  Each  of  two  different  DIVWAG  models  may  call  the 
In-flight  Attrition  Submodel  in  order  to  initiate  assessment  of  aircraft  losses 
on  a  specific  flight  leg  of  an  overall  flight  path.  These  models,  termed  pri¬ 
mary  callers,  include  the  Airmobile  Model  and  the  Reconnaissance  overlay  of 
the  Intelligence  and  Control  Model.  Also,  the  DIVWAG  event  scheduling  system 
may  call  the  In-flight  Attrition  Submodel  as  a  result  of  events  set  during  the 
course  of  assessment  of  aircraft  losses  on  a  specific  flight  leg.  The  latter 
type  of  call  is  termed  a  secondary  call.  All  primary  and  some  secondary  calls 
go  to  Section  1.  Primary  calls  carry  identification  of  caller,  a  specification 
of  the  flight  leg  to  be  assessed,  whether  it  is  the  first  or  subsequent  leg  of 
flight,  and  the  identity  of  the  air  unit  which  may  incur  losses.  Secondary 
calls  carry  this  information  plus  a  key  to  an  additional  storage  file  which 
can  contain  details  of  the  assessment  in  process. 
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(b)  Section  1.  This  section  identifies  segments  of  a  flight  leg 
where  attrition  may  occur.  In  keeping  with  the  event  sequencing  design  of 
DIVWAG,  such  segments  are  identified  prior  to  the  time  at  which  the  air  unit 
is  to  actually  traverse  the  flight  leg.  A  logical  flow  diagram  of  Section  1 
is  shown  in  Figure  IV-15-8. 

.1.  A  determination  is  made  as  to  whether  the  location  of  the 
air  unit  is  updated  to  the  end  of  the  flight  leg.  A  second  check  determines 
whether  the  air  unit  has  actually  reached  the  end  of  the  current  flight  leg. 

If  so,  control  is  returned  to  the  primary  caller,  so  that  the  next  flight  leg 
(if  any)  on  the  flight  path  may  be  presented  for  assessment.  If  the  air  unit 
has  not  reached  the  end  of  its  current  flight  leg,  the  current  position  of 
the  air  unit  is  taken  as  the  initial  point  of  reference  from  which  to  conduct 
a  search  for  ADCUs  which  may  have  an  effect  upon  the  air  unit. 

2_.  To  identify  those  segments  of  the  flight  leg  where  aircraft 
attrition  is  possible,  all  ADCUs  of  the  opposing  force  are  examined  against  two 
basic  criteria,  from  a  point  which  progresses  in  short  steps  (1000-meter  incre¬ 
ments)  from  the  beginning  to  the  end  of  the  flight  leg,  in  advance  of  the 
actual  air  unit.  One  criterion  is  whether  line  of  sight  exists  from  the 
center  of  the  ADCU  to  the  point.  The  other  criterion  is  whether  the  point  is 
within  maximum  effective  weapon  range  of  at  least  some^  of  the  longest  range 
weapons  on  the  ADCU.  If  both  criteria  are  met  for  any  ADCU  from  a  given  point, 
that  point  is  then  considered  to  be  within  a  flight  leg  segment  over  which  the 
air  unit  is  subject  to  possible  attrition.  If  two  adjacent  points  meet  both 
criteria,  the  step  interval  between  points  is  presumed  also  to  be  within  a 
flight  leg  segment  on  which  attrition  is  possible.  The  first  point  which 
fails  to  meet  both  criteria  marks  the  end  of  the  possible  attrition  segment, 
while  conversely  the  first  point  which  meets  both  criteria  marks  the  beginning. 

_3.  If  the  point  reaches  the  end  of  the  flight  leg  with  no 
possible  engagement  segments  being  found,  the  coordinates  of  the  air  unit  are 
updated  to  the  end  of  the  flight  leg  and  an  event  is  set  for  the  time  at  which 
the  air  unit,  at  its  assigned  flight  speed,  should  reach  the  end  of  the 
flight  leg.  This  event  calls  Section  1..  After  this  move  event  is  executed, 
control  returns  to  Section  1,  so  that  the  primary  caller  may  be  notified  and 
any  subsequent  flight  legs  may  be  presented  for  assessment. 

4^.  Section  1  also  keeps  track  of  which  ADCUs  are  involved 
in  meeting  both  of  the  above  criteria  as  a  basis  for  determining  the  end  of 
a  segment.  Whenever  an  ADCU  is  added  or  dropped  from  the  roster  of  those 
that  meet  both  criteria,  a  segment  is  considered  to  end.  Whenever  the  end 


2.  For  purposes  of  thfe  In-flight  Attrition  Submodel,  all  air  defense 
weapons  in  a  given  ADCU  are  assumed  to  be  evenly  distributed  on  the  circum¬ 
ference  of  a  circle  of  which  the  center  is  that  of  the  ADCU  and  the  radius 
is  half  of  the  width  or  depth  of  the  ADCU,  whichever  is  smaller. 


IV-15-34 


ENTER 
SECTION  l 


Figure  IV-15-8.  Macroflow  of  In-Flight  Attrition  Submodel 
(Section  1) 
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of  such  a  segment  is  found  by  this  section  of  the  submodel,  an  event  is  set 
to  enter  the  second  section  of  the  submodel  at  the  time  the  flight  is  antic¬ 
ipated  to  arrive  at  the  start  of  this  segment,  so  that  more  detailed  geometric, 
timing,  and  related  analysis  can  be  performed. 

(c)  Section  2.  Section  2  is  called  in  response  to  the  events 
set  in  Section  1  just  described.  Associated  with  each  such  event  are  data 
specifying  the  flight  leg  and  the  air  unit,  and  also  details  from  Section  1 
describing  the  segment  of  the  flight  leg  on  which  engagement  was  anticipated 
to  be  possible  including  the  identity  of  the  ADCU(s)  expected  to  engage.  A 
logical  flow  diagram  of  Section  2  is  shown  in  Figure  IV-15-9. 

1_.  The  first  step  in  Section  2  is  to  update  the  position  of 
the  air  unit  to  the  location  of  the  start  of  this  segment  of  the  flight  leg. 

2_.  To  perform  its  primary  task,  Section  2  must  examine  the 
current  status  and  air  defense  capability  of  each  air  defense  weapon  system 
in  each  ADCU  expected  by  Section  1  to  be  able  to  participate  on  this  segment 
of  the  flight  leg.  This  detailed  examination  by  weapon  type  reveals  which, 
if  any,  weapons  are  expected  to  be  capable  of  delivering  projectiles  which 
will  intercept  the  air  unit  on  this  segment  of  the  flight  leg.  Since  the 
ADCU  has  line  of  sight  on  this  segment,  all  contained  weapons  are  temporarily 
assumed,  for  this  examination,  also  to  have  line  of  sight.  The  range  of  each 
weapon  type,  however,  is  critical  in  this  examination.  Other  factors  such 
as  ammunition  supply  and  specific  weapon  capability  limits  are  also  considered 
here.  This  examination  also  determines  when  the  projectiles  fired  by  each 
capable  weapon  are  expected  to  begin  intercept  and  cease  intercept  of  the 
air  unit.  This  determination  of  timing  requires  consideration  of  the  imme¬ 
diately  preceding  activity  of  the  pertinent  weapons,  or  the  time  when  the 
air  unit  will  enter  range  of  a  given  weapon  type,  as  well  as  any  delay  times 
which  may  be  appropriate  to  the  specific  circumstances.  Delay  times  which 
may  be  appropriate  include  acquisition  delay,  reaction  time,  and  projectile 
time  of  flight.  For  example,  if  the  prior  activity  of  a  weapon  were,  for  a 
sufficient  period,  firing  at  this  air  unit,  then  no  delay  would  apply  to 
intercept  by  its  projectiles  on  this  segment  of  the  flight  leg.  If,  however, 
a  weapon  had  not  yet  acquired  the  flight,  then  acquisition  delay,  reaction 
time,  and  projectile  time  of  flight  would  all  be  applicable.  In  the  latter 
case,  it  might  be  determined  that  the  weapon  could  not  intercept  on  this 
segment  of  the  flight  leg.  In  this  manner,  Section  2  analyzes  the  capability 
and  timing  of  all  the  air  defense  weapons  in  the  pertinent  ADCU(s)  and  then 
sorts  out  the  results  by  weapon  type  according  to  anticipated  start  and  end 
of  projectile  intercept  with  the  air  unit  on  this  segment  of  the  flight  leg. 
These  sorted  results  reveal  the  flight  subsegments  within  each  of  which  the 
air  unit  is  expected  to  be  subject  to  attrition  by  a  unique  and  constant  set 
of  air  defense  weapons.  These  flight  subsegments  will  henceforth  be  referred 
to  as  constant  fire  subsegments  (CFS) . 
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SECTION  2  is  CALLED  ST: 

-  DIWAG  EVENT  STSTEX, 
NITS  EVENT  SET  ST: 
SECTION  1 


NITS  HELP  OP  DATA  ON  ISIS  SEGMENT 
"  OP  PLIGHT  LEG,  AS  SAVED  PSOM 
SECTION  1  ANALTSIS 


1 

I 

f  SECTION  3 


Figure  IV-15-9.  Macroflow  of  In-Flight  Attrition  Submodel 
(Section  2) 
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3..  For  each  CFS  established,  Section  2  sets  an  event  to  call 
Section  3  at  the  end  time  of  the  CFS,  for  the  final  attrition  calculations. 
Finally,  Section  2  sets  an  event  to  call  Section  1  at  the  end  of  the  last 
CFS  defined.  If  no  CFS  was  defined,  this  event  is  set  for  the  end  of  this 
segment  of  the  flight  leg. 

(d)  Section  3.  Section  3  is  called  in  response  to  the  attrition 
event  scheduled  in  Section  2.  Based  on  the  data  on  the  CFS  generated  in 
Section  2,  adjustments  for  status  changes  are  made  and  weapons  capabilities 
are  now  elaborated  upon  to  approximate  average  capability  over  the  CFS, 
suppressive  fire  and  effects  on  air  defense  weapons  are  accounted  for,  and 
the  aircraft  attrition  is  calculated.  A  logical  flow  diagram  of  Section  3 
is  shown  in  Figure  IV-15-10. 

1_.  To  prepare  for  attrition  calculations,  Section  3  references 
the  current  status  of  the  various  air  defense  weapon  types  which  were  anti¬ 
cipated  (by  Section  2)  to  be  participants  in  the  attrition  inflicted  on  the 
flight  during  this  CFS.  Current  time  (and  therefore  status)  is  for  the  end 
of  the  CFS.  The  attrition  calculations  must  exclude  weapons  which  are 
destroyed  and  weapons  which  are  suppressed.  The  current  number  of  weapons 
on  hand  is  accepted^  as  adequately  reflecting  weapons  destroyed. 

2_.  Because  of  the  potential  impact  of  suppression  on  results, 
a  look  back  is  made  to  CFS  start  time  to  evaluate  suppressive  effects  from 
all  sources  at  all  points  during  the  CFS.  Air  defense  suppressive  effects 
are  represented  by  air  defense  suppression  time  durations,  given  in  input, 
applied  by  Section  3  to  the  last  time  at  which  an  ADCU  was  attacked.  The 
entire  ADCU  is  assumed  to  be  affected  uniformly.  If  a  suppression  time 
duration  for  a  given  ADCU  is  not  found  to  overlap  any  part  of  the  CFS,  the 
ADCU  is  considered  to  be  firing  at  CFS  start  time.  In  this  case,  a  decision 

is  made  by  Section  3  as  to  whether  a  pair  of  escorts,  if  available,  would 

have  been  dispatched  to  suppress  the  ADCU.  If  the  decision  is  positive,  the 
suppressive  effect  of  the  escort  action  is  superimposed,  and  the  overlap  of 
suppression  duration  with  CFS  is  recalculated.  In  any  case,  the  fraction  of 
the  CFS  which  is  overlapped  by  the  foregoing  suppression  evaluations,  for  a 
given  ADCU,  is  used  in  the  attrition  calculation  to  degrade  the  amount  of 
fire  that  any  weapons  in  that  ADCU  can  place  on  the  air  unit  during  this 

CFS.  If  escorts  are  unavailable  to  attack  a  firing  ADCU,  or  if  the  firing 

ADCU  is  beyond  the  limits  of  attack  escorts  (to  the  sides  of  the  flight  path), 
a  request  for  quick-reaction  TACAIR  or  ground-based  artillery  fire  support  is 
made  to  the  Intelligence  and  Control  Model.  The  suppressive  effect  of  any 
such  external  fire  support  rendered,  however,  is  considered  only  on  subsequent 
CFS. 


3.  Ideally,  an  adjustment  should  be  made  to  reflect  average  number  on 
hand  over  the  length  of  the  CFS.  Provision  is  made  to  add  such  an  adjustment 
later.  As  long  as  the  segment  is  relatively  short,  however,  little  distortion 
should  result. 


IV- 15-3 8 


Figure  IV-15-10.  Macroflow  of  In-Flight  Attrition 
Submodel  (Section  3) 
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3_.  Preparatory  to  attrition  calculations,  Section  3 
establishes  the  X,  Y,  and  Z  coordinates  of  the  mid  point  of  the  CFS.  The 
mid  point  is  later  used  to  calculate  the  aspect  angle  of  the  air  unit  and 
its  slant  range  from  the  center  of  each  ADCU  participating. 

4_.  If  more  than  one  ADCU  was  determined  by  Section  2  to  be 
a  participant  on  the  CFS  currently  being  processed  for  attrition,  the  ADCUs 
are  considered  separately;  and  within  an  ADCU,  those  weapon  types  determined 
to  be  participants  are  also  considered  individually.  For  each  such  weapon 
type,  a  series  of  calculation  steps  is  performed,  employing  slant  range  and 
related  geometry  of  the  mid  point  of  the  CFS  and  reflecting  the  current  number 
of  weapons  and  their  capability  after  adjustment  for  air  defense  suppressive 
effects,  weather-visibility,  and  other  current  conditions.  Different  calcula¬ 
tion  procedures  are  used  for  missiles,  as  distinguished  from  guns.  The  result 
of  these  calculations  is  a  set  of  probabilities  of  kill,  by  weapon  type,  by 
aircraft  type  in  the  unit,  and  by  each  of  four  kill-type  categories.  Each 
missile  is  assumed  to  be  targeted  against  a  single  aircraft,  of  the  largest 
type  in  the  air  unit;  therefore,  resultant  missile  probabilities  of  kill  are 
considered  equivalent  to  fractional  losses.  Rounds  fired  from  guns  are 
assumed  to  be  equally  distributed  over  all  aircraft  in  the  flight  at  the 
start  of  the  CFS.  Gun  probabilities  of  kill  are,  therefore,  per  aircraft. 

_5.  Probabilities  of  kill  for  all  gun  weapon  types  in  all 
ADCUs  participating  are  then  combined  by  forming  the  product  of  the  respective 
probabilities  of  survival,  for  each  kill  type  and  aircraft  type.  The  aggre¬ 
gate  probability  of  kill  for  all  gun  weapons,  by  kill  type  and  aircraft 
type,  is  then  one  minus  the  respective  compound  probability  of  survival 
(1-PS).  Missile  losses  are  subtracted  first,  from  aircraft  in  the  air  unit. 
The  aggregate  gun  probability  of  kill  is  multiplied  by  the  remaining  air¬ 
craft  of  respective  type  to  generate  aggregate  losses  to  guns. 

b_.  Finally,  losses  to  aircraft  are  recorded,  and  the 
position  of  the  air  unit  is  updated  to  that  of  the  end  of  this  CFS. 

(3)  Section  1  Operating  Details: 

(a)  General.  This  subparagraph  is  a  supplement  to  the  preceding 
discussion  of  Section  1  of  the  In-flight  Attrition  Submodel.  The  general 
structure,  concept,  and  macroflow  of  Section  1  was  described  above.  This 
subparagraph,  in  contrast,  describes  how  Section  1  performs  its  principal 
functions.  Description  focuses  on  the  key  algorithms  and  logical  processes 
of  Section  1. 


(b)  Incoming  Data.  Four  essential  data  items  are  included  in 
the  data  which  accompany  a  call  to  Section  1.  The  first  of  these  items  is 
an  operation  code  which  causes  the  call  to  be  routed  to  Section  1.  The 
second  item  is  the  identity  of  the  air  unit  (IUID).  The  third  item  is  a 
flight  continuity  code  (JPASS)  which  denotes  whether  this  is  the  initial  or 
a  subsequent  pass  through  the  In-flight  Attrition  Submodel  on  this  flight 
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path.  The  fourth  item  is  a  code  which  can  be  used  to  return  to  the  primary 
caller  when  necessary.  Section  1  then  obtains  additional  data  as  needed. 

The  first  such  items  obtained  include  the  beginning  and  ending  X  and  Y  coor¬ 
dinates  of  the  current  flight  leg,  obtained  from  the  unit  status  record  of  the 
air  unit. 


(c)  Flight  Leg: 

1_.  Establishment  of  Z  Coordinates.  Since  the  flight  leg 
is  defined  so  far  only  in  the  X,  Y  plane,  the  beginning  and  ending  Z  coor¬ 
dinates  must  be  established  by  Section  1.  The  elevation  of  the  ground  at  the 
beginning  and  ending  X,Y  coordinates  is  obtained  and  the  height  of  the  flight 
above  terrain,  obtained  from  the  flight  altitude  variable  on  the  unit  status 
file  of  the  air  unit,  is  added  to  yield  the  Z  coordinates  of  the  beginning 
and  end  of  the  flight  leg,  in  meters. 


2_.  Orientation  of  the  Flight  Leg.  The  orientation  of  the 
flight  is  established  in  angular  terms,  so  that  coordinates  of  various  points 
along  the  flight  leg  can  be  readily  established.  Orientation  in  the  X,Y 
plane  is  represented  by  angle  B,  in  radians.  Angle  B  is  calculated  by  the 
expression: 


B 


-1 

tan 


(y/x) 
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where : 

x  =  difference  between  beginning  and  ending 
X  coordinates 

y  *  difference  between  beginning  and  ending 
Y  coordinates 


Orientation  of  the  flight  leg  in  the  vertical  plane  is  represented  by  angle 
R,  which  is  calculated  by  the  expression: 


R 


-1 

tan 


(Z2  -  ZL)/d) 


(IV-15-7) 


where : 

Z £  ■  ending  Z  coordinate 
Zj  -  begining  Z  coordinate 

d  -  V  +  y^ 


(IV-15-8) 
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The  flight  leg  is  assumed  to  be  a  straight  line  for  purposes  of  establishing 
position  of  the  air  unit.  Certain  trigonometric  functions  of  these  angles 
are  calculated  at  this  time  for  later  use  in  updating  positions. 

3^.  Air  Unit  Initial  Position.  The  position  of  the  air 
unit,  at  the  time  of  primary  call  to  Section  1,  is  at  the  beginning  of  the 
flight  leg.  At  the  time  of  secondary  call,  air  unit  position  may  have  been 
updated  appropriately  to  some  point  along  the  flight  leg. 

(d)  End-of-Flight-Leg  Check  for  Air  Unit.  In  case  the  air  unit 
position  has  been  updated,  through  steps  taken  in  other  parts  of  the  in-flight 
attrition  process,  to  the  end  of  the  current  flight  leg,  a  check  is  made. 

If  the  unit  is  at  the  end  of  the  flight  leg,  control  is  returned  to  the  primary 
caller  to  permit  presentation  of  the  next  flight  leg,  if  any. 

(e)  Initial  Position  of  Reference  Point  P.  On  the  first  pass 
through  Section  1,  signified  by  the  zero  value  of  the  pass  code  (third  item 
of  incoming  data),  the  position  of  the  reference  point,  P,  is  set  to  the 
location  of  the  air  unit,  which  is  at  the  beginning  of  the  flight  leg.  On 
all  subsequent  passes  through  Section  1,  signified  by  the  value  1  of  the  pass 
code,  point  P  is  set  to  the  position  it  held  at  the  end  of  the  last  pass,  as 
obtained  from  the  stored  X  and  Y  coordinates.  The  Z  coordinate  is  obtained 
by  use  of  the  utility  routine,  ELEVAT. 

(f)  Search  for  Enemy  Units.  From  the  look  point,  the  utility 
routine,  SEARCH,  is  used  to  generate  a  list  (list  1)  of  all  enemy  units 
within  a  specified  radius.  The  radius  is  limited,  to  reduce  unnecessary 
computation,  depending  on  the  altitude  of  the  flight  above  the  terrain  and 
foliage.  If  altitude  is  within  100  feet,  the  look  radius  is  set  to  4000 
meters.  If  altitude  is  between  100  and  1000  feet,  the  radius  is  set  to  6000 
meters.  If  altitude  is  between  1000  and  3000  feet,  radius  is  10,000  meters, 
while  for  over  3000  feet,  radius  is  20,000  meters. 

(g)  Developing  List  of  AD  Weapon  Types  Ranked  in  Order  of 
Decreasing  Range.  In  order  to  screen  the  list  of  enemy  units,  just  obtained, 
for  ADCUs  in  range,  a  list  of  all  AD  weapon  types  ranked  in  decreasing  order 
of  maximum  effective  weapon  range  is  formed.  The  weapon  types  specified  to 
have  AD  capability  are  obtained,  together  with  their  maximum  effective  ranges, 
from  the  input  data  file. 

(h)  Screening  for  ADCUs  in  Range.  The  list  of  enemy  units  within 
search  radius  is  screened  next  for  ADCUs  whose  longest  range  AD  weapon  can 
reach  the  reference  point,  P.  Each  enemy  unit  is  examined  to  see  if  it  con¬ 
tains  any  weapons  of  any  AD  type,  starting  with  the  longest  range  type, 
according  to  the  ranked  list  of  types.  If  any  AD  weapons  are  found,  the 
distance,  d,  between  point  P  and  the  ADCU  is  calculated  by  the  expression: 
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d  *  V<xp  ~  xu>2  +  <Yp  ~  Yu>2  ~  i/2  the  minimum  of  (IV-15-9) 

D  or  W 


where : 

Xp  *  X  coordinate  of  point  P 
Yp  =  Y  coordinate  of  point  P 
Xu  =•  X  coordinate  of  ADCU  center 
Yu  *  Y  coordinate  of  ADCU  center 
D  *  depth  of  ADCU,  in  meters 
W  *  width  of  ADCU,  in  meters 

The  distance,  d,  is  then  compared  with  the  maximum  effective  range  of  the 
weapon  type  to  determine  if  the  ADCU  is  within  range. 

(i)  Screening  for  Line  of  Sight.  If  the  ADCU  is  within  range, 
it  is  also  tested  for  line  of  sight.  The  line  of  sight  function,  LOS,  is 
used.  The  operation  of  tils  function  is  described  in  Chapter  4.  Function 
LOS  is  given  the  X,  Y,  and  Z  coordinates  of  the  imaginary  reference  point, 

P,  plus  a  flag  indicating  where  to  find  the  X,  Y,  and  Z  coordinates  of  the 
ADCU.  A  yes  or  no  answer  is  returned  for  existence  of  line  of  sight  between 
these  two  points.  While  this  screening  proceeds,  the  earliest  time  that  line 
of  sight  is  gained  by  any  ADCU  in  range  is  recorded  for  use  in  Section  2. 

(j)  Incrementing  Location  of  Reference  Point  P.  If  no  ADCU  is 
found  within  range  of,  and  with  line  of  sight  to,  the  air  unit  at  the  start 
of  the  flight  leg,  the  reference  point,  P,  is  stepped  ahead  along  the  flight 
path  by  an  incremental  distance,  and  the  search  and  screening  process  is 
repeated.  The  incremental  diatance  is  a  fixed  value  which  is  a  product  of 

a  variable  time  increment  and  the  flight  speed  of  the  air  unit.  The  time 
increment  t^,  is  calculated  by  the  reverse  process: 


tt  =  dj/s 


(IV-15-10) 


where : 


d^_  ■  incremental  distance 
s  ■  flight  speed  of  the  air  unit 

The  incremental  distance  is  hard-wired  and  is  chosen  to  compromise  adequately 
between  need  for  accuracy  of  results  and  need  to  minimize  computer  running 
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time.  The  value  currently  used  is  1000  meters.  The  new  coordinates  of  point 
P  are  calculated,  using  trigonometric  functions  of  the  angular  orientation  of 
the  flight  leg,  as  described  above.  The  new  coordinates  are: 


X  =  X0  +  D  •  cos  B 

Y  =  Y0  +  D  •  sin  B 

Z  =  ZQ  +  D  •  sin  R 


(IV-15-11) 

(IV-15-12) 

(IV-15-13) 


where: 

X0  =  initial  or  previous  X  coordinate  of  point  P 

Y0  »  initial  or  previous  Y  coordinate  of  point  P 

ZQ  =  initial  or  previous  Z  coordinate  of  point  P 

D  =  the  cumulative  distance  of  all  incrementation 

to  date  on  this  flight  leg 

B  and  R  are  angles  defined  in  paragraph  (c)2^  above,  Equations  IV-15-6 
and  IV-15-7. 

The  cumulative  distance,  D,  of  all  incrementation  to  date  on  this  flight  leg 
is  obtained  by  the  expression: 


D  =  s  •  t 


(IV-15-14) 


where : 

s  *  flight  speed  of  the  air  unit 

t  ■  the  cumulation  of  all  time  increments 
so  far  on  this  flight  leg. 

If  the  incrementation  should  push  the  new  coordinates  beyond  the  end  of  the 
flight  leg,  this  condition  is  detected,  and  the  coordinates  are  reset  to 
those  of  flight  leg  end. 

(k)  End-of-Flight-Leg-Check  for  Reference  Point  P.  The  check  to 
determine  whether  point  P  has  reached  the  end  of  the  flight  leg  is  made  on 
each  pass  through  the  point  P  incrementation  loop. 
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(1)  Flying  Air  Unit  to  End  of  Flight  Leg.  If  point  P  was  found 
to  have  reached  the  end  of  the  flight  leg,  no  further  preparatory  processing 
of  this  flight  leg  will  occur.  Accordingly,  the  location  of  the  air  unit  is 
«  updated  to  the  end  of  the  flight  leg.  This  is  done  by  resetting  air  unit 

coordinates  to  coordinates  of  flight  leg  end.  An  event  is  then  set  to  call 
Section  1  at  the  time  the  air  unit,  flying  at  its  given  speed,  will  reach  the 
end  of  the  flight  leg.  The  time  of  the  event,  t,  is  found  by  the  expression: 


t  =  tQ  +  dr/s  (IV-15-15) 

where: 

tQ  *  current  time 

dr  «=  distance  between  air  unit  current  location 
and  end  of  flight  leg 

s  -  flight  speed 

The  distance,  dr,  is  calculated  by  the  equation: 

dr  -  V(X2  -  Xx)2  +  (Y2  -  Yx)2  (IV-15-16) 

where : 

X^  =  current  X  coordinate  of  air  unit 
Y^  =  current  Y  coordinate  of  air  unit 
X2  *  flight  leg  end  X  coordinate 
Y2  »  flight  leg  end  Y  coordinate 


When  Section  1  is  called  at  this  event  time,  it  senses  that  the  air  unit 
is  at  the  end  of  the  flight  leg  and  therefore  returns  to  the  primary  caller 
so  that  any  following  flight  leg  may  be  presented  for  in-flight  attrition. 

(m)  Establishment  of  Possible  Engagement  Segments: 

1.  Finding  First  Start.  If,  for  the  first  time  on  this 
flight  leg,  after  the  screening  steps  described  above,  one  or  more  ADCUs 
remain  within  range  and  line  of  sight  to  the  reference  point,  P,  then  the  start 
of  the  first  possible  engagement  segment  on  this  flight  leg  has  been  found. 

The  coordinates  of  the  start  of  this  possible  engagement  segment  are  equated 
to  those  of  point  P.  The  identity  of  each  ADCU  which  could  possibly  engage 
at  this  point  is  placed  on  a  list  (list  A)  which  will  assist  in  finding  the 
end  of  the  first  engagement  segment. 
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2_.  Finding  First  End.  The  end  of  the  first  possible 
engagement  segment  on  this  flight  leg  is  sought  as  soon  as  the  start  has 
been  found.  To  find  the  end,  the  location  of  reference  point  P  is  stepped 
ahead  one  increment.  From  the  new  point  P,  a  new  search  for  enemy  units  is 
conducted,  and  all  units  found  are  screened  for  AD  weapon  range  and  line  of 
sight.  The  identity  of  each  ADCU  which  passes  the  screening  is  placed  on 
a  list  (list  B) .  The  contents  of  list  B  is  now  compared  with  the  contents 
of  list  A.  If  the  same  ADCUs  are  on  both  lists,  the  location  of  point  P 
is  again  incremented,  and  the  search  and  screening  steps  are  repeated  to 
generate  a  new  list  B.  As  soon  as  the  contents  of  lists  A  and  B  disagree, 
then  the  end  of  the  first  possible  engagement  segment  has  been  found.  The 
end  coordinates  of  this  segment  are  equated  to  those  of  point  P. 

3_.  Finding  Subsequent  Start  and  End.  The  start  and  end  of 
subsequent  possible  engagement  segments  of  the  flight  leg  are  found  in  the 
same  manner  as  described  in  the  preceding  two  paragraphs,  while  the  reference 
point,  P,  continues  to  progress  along  the  flight  leg.  The  end  of  a  previous 
segment  will  be  the  start  of  a  subsequent  segment  only  if  one  or  more  ADCUs 
remain  able  to  engage;  otherwise,  a  portion  of  the  flight  path  will  intervene 
on  which  no  engagement  is  possible. 

(n)  Setting  Event  to  Call  Section  2.  Whenever  the  end  of  a 
possible  engagement  segment  of  the  flight  leg  is  found,  an  event  is  set  to 
call  Section  2,  so  that  more  detailed  analysis  of  engagement  possibilities 
can  be  performed.  The  time  at  which  Section  2  will  be  called  is  set  to  the 
time  at  which  the  air  unit  should  arrive  at  the  start  of  the  possible  engage¬ 
ment  segment.  This  time  is  directly  available,  since  it  has  been  maintained 
and  updated  by  all  time  increments  used  in  moving  point  P  since  the  first 
call  to  Section  1. 

(o)  Data  Stored.  Whenever  an  event  to  call  Section  2  is  set, 
data  are  stored  for  later  use.  The  items  include  the  total  number  and  identity 
of  each  ADCU  on  list  A  for  the  particular  segment  of  the  flight  leg,  the 
beginning  and  ending  X  and  Y  coordinates  of  the  segment,  the  start  time  of 

the  segment,  and  the  time  at  which  line  of  sight  is  first  gained  (air  unit 
mask  time),  if  at  all,  on  this  segment. 

(4)  Section  2  Operating  Details: 

(a)  Incoming  Data.  The  same  four  essential  items  which  are 
incoming  to  Section  1  also  accompany  a  call  to  Section  2.  These  are  the  call 
routing  code,  the  identity  of  the  air  unit  (IUID),  the  flight  continuity  code 
(JPASS) ,  and  the  code  used  by  Section  1  to  return  to  the  primary  caller. 

Section  2  then  obtains  additional  data,  including  the  data  stored  by  Section 
1  (see  paragraph  (3)(o)  above,  AD  weapon  characteristics)  and  the  unit  status 
record  of  the  air  unit,  containing  the  X  and  Y  coordinates  of  the  flight  leg. 
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(b)  Update  of  Air  Unit  Location.  An  initial  step  taken  by 
Section  2  is  to  move  the  air  unit  to  the  X,Y  coordinates  of  the  start  of  the 
possible  engagement  segment.  These  coordinates  are  included  in  the  data 

•  stored  by  Section  1. 

(c)  Length  of  Possible  Engagement  Segment.  The  length,  L,  of 
the  possible  engagement  segment  is  calculated  by  the  expression: 

L  =V(xe  ~  xb)2  +  <Ye  -  V2  (IV-15-17) 

where : 

X  =  X  coordinate  of  end 
e 

Yg  =  Y  coordinate  of  end 

X^  =  X  coordinate  of  beginning 

Y^  *  Y  coordinate  of  beginning 

(d)  Setting  Flight  Continuity  Flag.  If  this  is  the  first  time 
that  Section  2  has  been  called  for  this  air  unit's  current  flight  through 
hostile  air  space,  the  flight  continuity  flag,  JPASS,  an  essential  incoming  item 
of  data,  will  enter  with  a  value  of  zero,  which  was  set  by  the  primary  caller. 
Section  2  checks  on  the  value  of  JPASS,  and  if  it  is  found  to  be  zero,  resets  it 
to  a  value  of  one.  The  value  one  remains  for  all  subsequent  flight  legs  and 
signifies  to  the  various  parts  of  the  In-flight  Attrition  Submodel  that  any 
call  with  this  value  is  a  continuation  of  a  flight  already  in  progress,  rather 
than  the  start  of  a  new  flight. 

f 

(e)  Determining  Initial  Value  of  Last  Event  Time.  The  time  of 
the  end  of  the  last  constant  fire  subsegment  (CFS)  defined  for  this  air  unit 
flight  path  is  an  important  reference  value  throughout  Section  2.  If  this 
is  the  first  time  that  Section  2  is  called  for  a  given  air  unit  flight  path, 
no  prior  CFS  can  have  been  defined.  In  this  case,  Section  2  sets  the  last 
event  time  variable,  LASTET,  equal  to  the  start  time  of  this  possible  engage¬ 
ment  segment  of  the  flight  leg,  as  stored  in  Section  1.  If,  however,  this  is 
not  the  last  call  to  Section  2  for  the  given  air  unit  flight  path,  last  event 

*  time  is  found  from  the  stored  records  of  CFS  found  on  a  previous  pass  through 
Section  2.  In  case  no  record  yet  exists,  the  value  generated  on  the  first 
'  pass  is  used. 

*  (f)  Processing  ADCUs  Which  Can  Possibly  Engage.  Each  ADCU 
designated  by  Section  1  as  possibly  being  able  to  engage  the  air  unit  on 
this  segment  of  the  flight  leg  is  put  through  a  series  of  processing  steps. 

t 
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.1.  Finding  Air  Unit  Crossover  Point  Versus  this  ADCU. 

The  crossover  point  is  the  point  on  the  line  through  the  ends  of  this  possible 
engagement  segment  which  is  nearest  to  the  ADCU.  The  position  of  the  cross¬ 
over  point  is  returned  in  terms  of  a  variable  which  reflects  the  fractional 
position  of  the  point  between  the  begin  and  end  of  the  segment,  or,  if  the 
point  is  beyond  an  end,  the  fractional  degree  of  excess,  with  a  sign  to  indi¬ 
cate  the  end  exceeded. 

2_.  Screening  Weapon  Type  Capability  in  This  Situation. 

Within  a  given  ADCU,  the  capabilities  of  each  AD  weapon  type  are  first  grossly 
screened  to  eliminate  from  further  consideration  weapon  types  which  cannot 
engage  in  this  particular  situation.'  A  series  of  screening  checks  is  employed 
based  on  the  current  status  of  the  ADCU. 

a^.  Weapon  Defense  Responsibility  Radius.  If  the  air 
unit  is  outside  the  input-specified  radius  of  defense  responsibility  of  a 
given  AD  weapon  type,  that  type  is  dropped  from  further  consideration.  Dis¬ 
tance,  d,  between  air  unit  and  AD  weapon,  for  this  check,  is  obtained  by  the 
equation: 


f(X.  -  X  )2  +  (Yb  -  Yu) 2  +1/2  the  minimum  of 

D  or  W 


(IV-15-18) 


where : 


Xb  =  X  coordinate  of  beginning  of  possible  engagement 
subportion 

Yb  =  Y  coordinate  of  beginning  of  possible  engagement 
subportion 

Xu  *  X  coordinate  of  ADCU  center 

Yu  *  Y  coordinate  of  ADCU  center 
D  »  depth  of  ADCU,  in  meters 
W  »  width  of  ADCU,  in  meters 

b_.  AD  Weapons  on  Hand.  If  any  AD  weapons  of  this  type 
remain  on  hand  (i.e.,  remain  undestroyed),  this  type  is  considered  further; 
otherwise,  it  is  dropped. 

c_.  Ammunition  on  Hand.  This  weapon  type  must  have  some 
of  the  proper  type  of  ammunition  on  hand  for  the  weapon  type  to  be  considered 
further. 
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d_.  Weather-Visibility  Condition.  The  current  weather- 
visibility  condition  is  obtained  by  use  of  the  utility  routine  WETTHR,  which 
tells  whether  it  is  day  or  night  and  good  or  poor  weather.  Input  data  for 
the  weapon  type  specifies  whether  the  weapon  is  capable  of  firing  effectively 
in  either  nighttime  or  poor  weather  conditions.  If  a  condition  prevails  in 
which  the  weapon  cannot  fire  effectively,  it  is  not  considered  further. 

e..  Aircraft  Altitude.  Maximum  and  minimum  aircraft 
altitude  capability  of  the  AD  weapon  type,  from  input  data,  is  compared  with 
aircraft  altitude.  If  the  aircraft  altitude  is  within  weapon  capability 
limits,  the  weapon  continues  in  consideration. 

£.  Aircraft  Speed.  Input  data  also  contain  maximum  and 
minimum  aircraft  speed  capability  of  the  weapon  type.  If  the  aircraft  is 
within  weapon  capability  limits,  the  weapon  type  continues  to  be  considered. 

IR  Lock-On  Boundary.  Input  data  provide  a  simplified 
boundary  representation  for  the  capability  of  infrared-seeking  missiles  to 
achieve  lock-on.  The  input  is  a  set  of  boundary  distances  as  a  function  of 
seven  horizontal  aspect  angles  of  the  aircraft  trajectory.  For  comparison 
with  the  input  data,  the  horizontal  aspect  angle  of  this  air  unit  and  its 
distance  from  the  weapon  is  calculated.  Boundary  distance  is  interpolated 
linearly,  between  the  nearest  two  of  the  seven  input  aspect  angles.  Air 
unit  distance  from  the  weapon  is  the  same  distance,  d,  as  calculated  for  com¬ 
parison  with  defense  responsibility  radius,  above.  Horizontal  aspect  angle 
of  the  air  unit  trajectory  is  calculated  with  the  assistance  of  the  utility 
routine  DISTPL.  This  routine  is  given  the  begin  and  end  X,Y  coordinates  of 
the  possible  engagement  segment  and  the  X,  Y  coordinates  of  the  ADCU,  and 
returns  a  perpendicular  distance,  b,  from  the  ADCU  to  the  line  passing 
through  the  begin  and  end  coordinates  (see  Figure  IV-15-11).  The  third  side, 
a,  of  the  right  triangle  of  sides  a,  b,  d  is  calculated  by  the  expression: 


a 


(IV-15-19) 


The  horizontal  aspect  angle  is  defined  here 
representing  the  perpendicular  distance,  b, 
d.  The  tangent  of  this  aspect  angle  equals 
therefore  calculated  by: 


as  the  angle  A,  between  the  sides 
and  the  ADCU-to-begin  distance, 
a/b.  This  aspect  angle.  A,  is 


-1 

A  *  tan 


(a/b) 


(IV-15-20) 


If  the  interpolated  boundary  distance  exceeds  distance  d,  the  weapon  continues 
to  be  considered. 
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h.  Slew  Race.  The  angular  rate  of  the  aircraft  with 
respect  to  the  ADCU  is  calculated  and  compared  with  the  maximum  slew  or 
tracking  rate  capability  of  the  AD  weapon,  from  input  data.  Weapon  capability 
must  exceed  aircraft  angular  rate  for  the  weapon  to  be  considered  further. 
Aircraft  angular  rate,  *,  is  calculated  by  the  expression: 

6  =  cosine  A  •  s/d  (IV-15-21) 


where : 

A  =  horizontal  aspect  angle,  as  defined  in  preceding 
paragraph 

s  =  speed  of  air  unit 

d  =  distance  between  ADCU  and  air  unit  as  used 
in  preceding  paragraph. 

3_.  Range  of  AD  Weapons.  For  use  in  determining  the  portions 
of  the  flight  path  that  each  weapon  type  can  reach,  the  position  of  weapons 
in  tf*  ADCU  must  be  considered.  The  AD  weapons  are  assumed  to  be  uniformly 
d  tributed  on  the  circumference  of  a  circle  of  which  the  diameter  is  the  mini¬ 
mum  of  the  depth  and  width  of  the  ADCU.  Thus  half  the  diameter  of  that  circle 
is  added  to  the  maximum  effective  weapon  range  of  each  weapon  type  when 
considering  range  intercept  points  on  the  flight  path. 

^4.  Determining  Range  Intercept  Points  on  Flight  Path.  To 
determine  where  on  the  flight  path  the  range  of  any  weapon  type,  in  a  given 
ADCU,  can  begin  to  intercept  and  will  cease  intercepting,  the  adjusted  weapon 
range  as  defined  in  the  preceding  paragraph  is  used.  These  two  points  of 
intercept  are  determined  by  using  the  utility  routine  CHORD.  This  routine 
is  given  the  X,Y  coordinates  of  the  ADCU,  the  X,Y  beginning  and  ending 
coordinates  of  the  possible  engagement  segment,  and  the  adjusted  AD  weapon 
range.  This  routine  returns  the  X  coordinates  of  the  two  points  where  a  line 
extended  through  the  possible  engagement  segment  is  intercepted  by  the  range. 
The  X  coordinate  corresponding  to  the  start  of  range  intercept  is  identified 
and  so  labeled  (XI) ,  as  is  the  X  coordinate  corresponding  to  the  end  of  range 
intercept  (X2) .  This  identification  is  accomplished  by  reference  to  the  order 
of  the  X  values  of  the  beginning  and  ending  of  the  possible  engagement  segment 
together  with  those  of  the  two  points.  The  corresponding  Y  coordinate  for 
each  of  these  two  intercept  limits  is  obtained  from  the  line  of  the  possible 
engagement  segment  by  the  expression: 


vp  •  <W  '  'vxbi  I  +  Vb  HV-15-M) 


t 


I 


U,> 


where : 


xb 

Yb 

Xe 


X  coordinate  of  beginning 
Y  coordinate  of  beginning 
X  coordinate  of  ending  of 


of  possible  engagement  segment 
of  possible  engagement  segment 
possible  engagement  segment 


Ye  -  Y  coordinate  of  ending  of  possible  engagement  segment 
Xp  =  X  coordinate  of  a  range  intercept  point 
Yp  =  Y  coordinate  of  a  range  intercept  point 

.5.  Excluding  Irrelevant  Range  Intercept  Points.  Range 
intercept  points  may  be  generated,  by  the  foregoing  process,  which  are  irrel¬ 
evant  to  this  possible  engagement  segment  of  the  flight  leg.  Such  point  pairs 
must  be  excluded  from  consideration  on  this  segment,  since  they  are  considered 
on  either  prior  or  subsequent  segments.  To  identify  and  exclude  such  point 
pairs,  it  is  determined  whether  the  intercept  points  lie  on  the  engagement 
segment  or  on  extensions  thereof.  If  both  points  lie  outside  the  same  end  of 
the  possible  engagement  segment  they  are  clearly  excludable,  since  they  are 
properly  considered  in  another  segment.  If  the  points  straddle  this  possible 
engagement  segment  they  cannot  be  excluded. 


6..  Calculating  Times  of  Start  and  End  of  Range  Intercept. 

If  both  range  intercept  points  fall  within  the  possible  engagement  segment, 
their  times  can  be  calculated  directly.  If,  however,  one  point  is  within  and 
the  other  point  is  outside,  or  if  the  points  straddle  the  segment,  an  adjust¬ 
ment  is  necessary. 


a.  Both  Intercept  Points  Within  Segment.  If  both  range 
intercept  points  lie  within  the  possible  engagement  segment,  the  time  for 
each,  t,  is  calculated  by  the  expression: 


t  “  b  +  f  '  d/s 


(IV-15-23) 


where : 

b  »  time  of  beginning  of  this  possible  engagement  segment 

f  *  the  fraction  of  distance,  between  beginning  and  end  of 
the  segment,  at  which  the  point  lies 

d  -  the  length  of  the  segment  (see  paragraph  e(4)(c)  above) 

s  ■  speed  of  the  air  unit. 
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b_.  One  Point  Within  Segment.  If  only  one  of  the  two 
points  lies  within  the  possible  engagement  segment,  time  for  the  inside 
point  is  calculated  as  in  the  preceding  paragraph.  Time  for  the  outlying 
point,  however,  is  set  equal  to  the  time  of  the  end  of  the  segment  on  which 
the  point  lies  outside. 

£.  Points  Straddling  Segment.  If  the  two  range  intercept 
points  straddle  the  possible  engagement  segment,  the  time  of  each  point  is 
set  equal  to  the  time  of  that  end  of  the  segment  outside  which  the  point  lies. 

Calculating  Time  Delays  to  Start  of  Projectile  Intercept, 
Depending  upon  the  specific  circumstances,  a  delay  may  occur  which  affects 
the  time  at  which  projectiles  from  the  given  weapon  type  intercept  the  air 
unit.  Up  to  three  types  of  time  delay  may  be  included  in  the  total  delay 
imposed.  These  types  are  detection  delay,  fire/launch  delay,  and  time  of 
projectile  flight  to  target.  Means  used  to  calculate  these  delays  are  de¬ 
scribed  in  this  paragraph.  The  determination  of  the  applicability  of  and 
method  of  applying  any  or  all  of  these  delays  is  discussed  in  paragraph  j3 
below. 


£.  Detection  Delay.  In  those  circumstances  where 
detection  delay  is  applicable,  it  is  calculated  from  data  provided  in  input 
tables.  The  input  tables  contain  data  on  probability  of  detection  of  air¬ 
craft  by  one  AD  weapon,  within  some  cut-off  time,  and  corresponding  data  on 
median  time  delay,  from  entry  of  the  target  into  line  of  sight  until  detec¬ 
tion  of  the  target.  Some  of  the  data  can  be  obtained  from  Combat  Develop¬ 
ments  Command  Experimentation  Center  test  results.  Data  are  provided  for 
three  basically  different  types  of  an  engagement  situation  that  the  model 
may  be  called  upon  to  simulate.  Means  of  detection  used  and  other  conditions 
are  assumed  to  be  inherent  to  each  of  the  three  types  of  an  engagement  situa¬ 
tion.  These  types  are: 

.  AD  guns  and  short  range  missiles  against  average 
type  helicopters  at  nap-of-the-earth  altitude,  with 
average  background  clutter /contrast  for  the  terri¬ 
tory  being  gamed. 

.  AD  guns  and  short  range  missiles  against  average 
type  fixed-wing  aircraft,  under  average  conditions. 

.  Medium  and  long  range  AD  missiles  against  average 
type  fixed-wing  aircraft,  under  average  conditions. 

Data  are  provided  for  three  groups  of  aircraft,  each  at  four  slant  ranges.  For 
a  specific  situation,  the  model  interpolates  linearly  between  the  input  aata 
points  to  obtain  the  specific  input  median  delay  value  for  one  AD  weapon.  Since 
an  ADCU  may  contain  a  number  of  AD  weapons  which  are  in  a  position  to  detect, 
the  model  must  adjust  the  input  delay  for  this  number.  Also,  since  the  field 
test  data  are  often  subject  to  a  cut-off  time  and  therefore  incomplete,  adjustment 
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must  be  made  for  the  missing  data  reflected  by  a  probability  of  detection, 
within  cut-off  time,  of  less  than  1.0.  These  adjustments,  and  the  selection 
of  a  specific  delay  value,  assume  that  detection  delays  are,  in  reality,  log- 
normally  distributed.  Also,  it  is  assumed  that  the  standard  deviation  (in  the 
log  domain)  of  the  distribution  can  be  satisfactorily  estimated  by  the 
relationship : 


s  *  y  •  ln(t) 


(IV-15-24) 


where: 

s  =  estimated  standard  deviation  (in  log  domain) 
t  =  median  detection  delay 

y  =  a  constant  for  the  type  of  data  situation  being 
considered.  This  constant  can  be  derived  from 
field  test  data.  Examination  of  data  from  the 
Combat  Developments  Command  Experimentation 
Center  43.6  test  yields  a  value  of  about  0.25. 

The  adjustment  for  incomplete  field  test  data  is  then  made  by  the  equation: 


tla  =  t1  •  e  "S1  *  fl  (Pd/2) 


(IV-15-25) 


where : 

t^a  =  adjusted  median  detection  delay  for  one  AD  weapon 
t^  =  input  median  detection  delay  for  one  AD  weapon 

»  estimated  standard  deviation  for  the  field 
test  data  (in  log  domain) 

Pj  -  probability  of  detection  by  one  AD  weapon, 

within  the  cut-off  time  of  the  field  test  data. 

4 

f^  ■  a  function  whicn  returns  an  approximation  of 
the  cumulative  area  beneath  the  normal  curve 
corresponding  to  a  position  along  the  curve, 


4.  Adapted  from  Hastings,  Approximations  for  Digital  Computers.  Princeton 
University  Press,  1955,  p.  187. 
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in  standard  deviations,  represented  by  the  value 
in  the  parentheses.  Utility  function  DNORM 
is  used. 

The  adjustment  for  the  actual  number  of  observing  AD  weapons  is  then  made 
by  a  method  of  successive  approximations,  using  the  following  formula  for 
the  cumulative  lognormal  probability  distribution: 


-  x2 

2  •  dx  (IV-15-26) 


tn  »  median  detection  delay  for  n  AD  weapons 
t^a  *  adjusted  median  delay  for  one  AD  weapon 
Sd  ■  estimated  standard  deviation  for  the  test  data 


A  trial  value  of  tn  (actually  is  inserted  in  this  equation.  The 

formula  is  evaluated,  and  the  resulting  value  of  $(x),  representing  the 
probability  of  detection  by  one  weapon  within  time  t,  is  then  transformed 
to  an  estimate  of  the  probability  for  n  weapons,  Fdn,  by  the  formula: 


Pdn  -  1.  -  (1.  -  *(x))n 


(IV-15-27) 


where : 


n  *  the  total  number  of  AD  weapons  in  this  ADCU 

The  value  of  Pdn  is  then  compared  with  the  desired  value  of  0.5,  representing 
the  probability  corresponding  to  the  desired  median  time  delay.  By  adjusting 
tn  in  the  proper  way,  several  reiterations  yield  a  value  of  <$(x)  acceptably 
close  to  (within  +.01)  the  desired  0.5.  The  latest  tn  value  is  then  used 
as  the  median  detection  delay  for  n  AD  weapons.  The  detection  delay  value 
used  to  establish  the  start  of  the  CFS  is  now  selected  from  the  lognormal 
distribution  of  delays,  based  on  the  median  value  just  derived  for  n  AD 
weapons.  This  selection  of  delay  is  made  by  the  equation: 
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where : 

t  =  median  deteccion  delay  for  n  AD  weapons 

Sn  =  estimated  standard  deviation  for  n  AD  weapons 

=  y  "  In  (tn)  ( y =  constant,  see  above) 

U  =  a  random  normal  deviate 

=  f2  (a  random  number  from  a  uniform  distribution 
between  0.0  and  1.0) 

and  where: 

f2  =  a  function  which  returns  an  approximation"5  of  the 
number  of  standard  deviations  corresponding  to 
the  cumulative  fraction  of  area  beneath  the  normal 
curve,  as  represented  by  the  random  number. 

Utility  function  FNORM  is  used. 

J).  Firing/Launch  Delay.  Firing/launch  delay,  when 
applicable,  is  obtained  from  the  weapon  input  data  and  is  a  constant  for 
each  AD  weapon  type. 


c_.  Time  of  Projectile  Flight  to  Target.  When  applicable, 
time  of  projectile  flight  to  target  is  approximated  by  a  two-step  reiteration 
process.  The  first  step  uses  the  current  location  of  the  air  unit  from  which 
to  calculate  slant  range  to  the  ADCU  center.  Using  this  slant  range,  time 
of  flight  to  initial  target  location  is  calculated  or  interpolated  for  the 
weapon.  The  target  is  then  moved,  according  to  its  flight  speed  and  direc¬ 
tion,  to  the  position  it  would  have  reached  after  projectile  time  of  flight 
to  the  initial  target  location.  For  the  second  step,  time  of  flight  is  re¬ 
calculated  or  reinterpolated  to  the  new  target  location.  The  second  time  of 
flight  is  then  used  as  an  approximation  for  delay  applications.  Slant  range 
is  calculated  from  the  X,  Y,  and  Z  coordinates  of  the  air  unit  and  the  ADCU. 
Distance  in  the  X,Y  plane  is  calculated  first.  Difference  in  Z  coordinates 
is  then  used  to  calculate  slant  range.  Both  calculations  use  the  Pythagorean 
theorem.  Given  the  slant  range,  time  of  flight  for  a  missile  is  interpolated 
from  the  input  data  table  of  time  of  flight  versus  slant  range  for  the  weapon 
type.  For  guns,  time  of  flight  is  calculated  by  the  formula: 


5.  Adapted  from  Hastings,  Approximations  for  Digital  Computers,  p.  192. 
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where : 

r  =*  slant  range 

v  =  muzzle  velocity  of  the  weapon  type 
c  =  projectile  drag  coefficient  of  the  weapon  type. 

8_.  Application  of  Time  Delays.  Tne  applicability  of  any 
of  the  three  types  of  time  delay  to  projectile  intercept,  as  well  as  the 
method  of  application,  depends  upon  the  current  nature  and  history  of  the 
engagement  situation  between  the  air  unit  and  air  defense  weapons. 

«i.  Detection  Delay.  Detection  delay  is  applied  whenever 
this  A DCU  must  acquire  the  air  unit.  This  ADCU  must  acquire  the  air  unit 
when  it  has  been  either  out  of  range  or  masked  to  all  ADCUs  immediately  prior 
to  the  current  possible  engagement  segment  of  the  flight  leg.  Considered 
from  the  reverse  standpoint,  if  another  ADCU  is  currently  engaging  the  air 
unit,  or  has  recently  acquired  it  and  is  about  to  engage  it,  the  model  does 
not  apply  detection  delay  to  the  ADCU  currently  being  processed.  Good  com¬ 
munication  is  thus  assumed  between  nearby  ADCUs.  If  this  ADCU  must  acquire 
the  air  unit,  detection  delay  is  applied  directly  to  only  the  first  CFS  on 
this  possible  engagement  segment.  This  delay  may  indirectly  affect  other 
CFS,  however,  since  by  definition  they  must  follow  the  first  CFS.  Detection 
delay,  when  applicable,  is  applied  to  the  time  that  the  air  unit  enters 
line  of  sight  of  this  ADCU.  This  time  was  calculated  in  Section  1  and  stored 
for  use  here.  The  determination  of  whether  this  ADCU  must  acquire  is  made 
by  checking  on  whether  the  last  possible  engagement  segment  of  the  flight 
path  is  contiguous  with  the  possible  engagement  segment  currently  being 
processed.  If  they  are  contiguous,  no  detection  delay  is  applied.  If  they 
are  not  contiguous,  detection  delay  is  applied  as  just  described. 

b_.  Firing/Launch  Delay.  A  firing/launch  delay  is 
applied  (added)  whenever  a  detection  delay  is  applied.  In  addition,  firing/ 
launch  dulay  is  applied  if  the  air  unit  enters  range  of  this  ADCU  before 
line  of  sight  to  this  ADCU,  when  other  ADCUs  are  already  participating.  In 
the  latter  case,  it  is  assumed  that  this  ADCU  has  been  continually  informed 
by  the  other  participants  as  to  the  course  and  position  of  the  air  unit; 
therefore,  this  ADCU  knows  where  to  look,  but  cannot  fire  until  the  flight 
enters  line  of  sight.  In  this  case,  it  is  assumed  that  detection  time  is 
negligible,  but  that  reaction,  tracking,  or  launch  time  must  be  applied,  as 
represented  by  the  input  firing/ launch  delay.  When  applied  independent  of 
detection  delay,  firing/launch  delay  is  added  to  the  time  of  entry  into  line 
of  sight,  and  only  on  the  first  CFS,  similarly  to  detection  delay. 
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c_.  Time  of  Projectile  Flight  to  Target.  Time  of 
projectile  flight  delay  is  applied  (added)  only  when  firing/launch  delay  is 
applied,  and  similarly  is  applied  only  to  the  first  CFS. 

d^  Total  Delay.  The  total  delay  applied  is  the  sum  of 
the  applicable  delays  as  described  above.  Three  total-delay  cases  result. 
Total  delay  in  the  first  case  is  the  sum  of  detection  delay,  firing/launch 
delay,  and  projectile  time  of  flight.  In  the  second  case,  the  total  is  the 
sum  of  firing/launch  delay  and  projectile  time  of  flight.  In  the  third  case, 
the  total  is  zero  delay. 

9_.  Screening  for  Intercept  Duration.  If  any  delay  time  is 
directly  applied  to  a  particular  weapon  type  in  a  given  ADCU,  the  duration 
of  time  over  which  projectiles  from  this  weapon  type  can  intercept  the  air 
unit  may  be  affected.  Other  weapon  types  may  also  be  indirectly  affected. 
Since  total  delay  is  always  added  to  time  of  entry  into  line  of  sight,  and 
since  line  of  sight  time  in  some  cases  will  precede  the  start  of  this  possible 
engagement  segment  the  start  of  projectile  intercept  time,  ts,  is  established 
for  this  weapon  type  as  follows: 


ts  -  Max  of  (tffl  or  (tlo8  +  d)) 


(IV-15-30) 


where: 

tm  =  start  time  of  this  possible  engagement  segment 
t^og  «  time  of  entry  into  line  of  sight 
d  *  total  delay  applied. 

This  time  of  projectile  intercept  start  now  supersedes  the  range  intercept 
start  time  calculated  earlier  (paragraph  ^  above).  Next,  the  time  of 
projectile  intercept  start  is  compared  with  the  time  of  range  intercept  end, 
calculated  earlier.  If  there  is  no  positive  projectile  intercept  duration, 
this  weapon  type  is  dropped  from  further  consideration  on  this  possible 
engagement  segment.  The  time  of  detection  by  this  weapon  is  saved,  however, 
for  use  in  considering  other  weapon  types  in  this  ADCU.  This  time  of  detec¬ 
tion  is  the  base  point  for  determing  if  any  other  weapons  can,  because  of 
possible  lower  fire/launch  and  projectile  flight  times,  intercept  the  target. 

10.  Storing  Intercept  Events.  As  each  weapon  type  in  each 
ADCU  which  can  possibly  engage  on  this  subportion  of  the  flight  leg  is  pro¬ 
cessed,  the  results  are  temporarily  stored  for  further  processing.  For  each 
weapon  type  that  passes  the  foregoing  screening,  four  items  of  data  are  stored 
for  each  of  the  two  intercept  events,  the  start  of  projectile  intercept  and 
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the  end  of  projectile  intercept.  The  four  items  stored  are  the  identity  of 
the  ADCU,  the  identity  of  the  weapon  type,  the  event  time,  and  a  flag  indicat¬ 
ing  whether  the  event  is  a  start  or  an  end  event. 

I 

(g)  Processing  Intercept  Events.  When  all  ADCUs  expected  to 
,  participate  on  this  possible  engagement  segment  of  the  flight  have  been  pro¬ 
cessed,  the  accumulation  of  resulting  intercept  events  is  sorted  and  analyzed 
to  establish  CFS.  Within  each  CFS  a  unique  set  of  ADCU-weapon  type  combina¬ 
tions  are  anticipated  to  have  projectiles  intercepting  the  vicinity  of  the 
air  unit. 

• 

1_.  Ranking  Intercept  Events  by  Increasing  Event  Time.  The 
accumulated  intercept  events  are  first  ranked  in  order  of  increasing  event 
time, 

2_.  Finding  CFS  and  Setting  Event  for  Each  to  Call  Section  3. 
The  ranked  intercept  events,  temporarily  stored  on  a  list  called  TEMPI,  are 
considered  one  at  a  time,  starting  with  the  earliest  event  time.  The  first 
step  is  to  compare  the  time  of  this  event  with  the  time  of  the  last  event. 
(Initially,  before  any  CFS  is  established  for  this  flight  path,  last  event 
time  is  set  to  start  of  the  possible  engagement  segment.  Subsequently,  last 
event  time  is  stored  with  CFS.)  If  the  time  of  this  event  is  the  same  as 
that  of  the  last  event,  and  if  this  event  is  a  start  event,  the  identity  of 
the  ADCU  and  the  identity  of  the  weapon  type  are  entered  on  a  second  list, 
called  TEMP 2,  and  the  next  event  on  TEMPI  is  considered.  The  entry  in  TEMP2 
signifies  that  the  identified  ADCU-weapon  type  combination  is  currently 
intercepting.  If  the  second  event  on  TEMPI  has  a  time  larger  than  last  event 
time,  and  if  it  also  is  a  start  event,  a  check  is  made  to  see  if  any  ADCU- 
weapon  combination  is  currently  intercepting  (is  currently  on  TEMP2) .  If 
there  is,  a  CFS  record  is  built  and  stored  and  an  event  is  set  in  the  DIVWAG 
event  scheduling  system  to  call  Section  3  of  the  In-flight  Attrition  Submodel 
at  the  time  of  this  event  from  TEMPI,  which  is  the  end  of  the  CFS.  A  key  is 
sent  with  the  call  so  that  Section  3  can  find  the  stored  CFS  record.  This 

•  record  contains  four  items  of  data.  The  items  are  last  event  time,  event 
time,  identity  of  ADCU,  and  identity  of  the  AD  weapon  type.  The  ADCU  and  AD 
weapon  data  are  copied  from  TEMP2,  to  include  as  many  ADCU-weapon  type  com¬ 
binations  as  are  currently  intercepting.  After  setting  the  DIVWAG  event,  the 
value  of  the  last  event  time  is  updated  to  that  of  the  event  still  being 
processed  and,  if  this  event  from  TEMPI  is  a  begin  event,  it  is  added  to  TE>fP2. 
If,  however,  this  were  an  end  event,  and  if  its  same  ADCU-weapon  type  combina- 

,  tion  were  on  TEMP2,  then  the  counterpart  on  TIMP2,  would  be  removed,  signifying 
that  that  ADCU-weapon  type  combination  is  no  longer  intercepting.  The  next 
4  event  from  TEMPI  is  then  considered.  If  any  event  from  TEMPI  has  an  event 

time  which  is  not  larger  than  the  last  event  time,  it  is  simply  added  to  TEMP2 
in  the  manner  already  described.  All  ADCU-weapon  type  combinations  currently 

*  intercepting  are  thus  kept  listed  on  TEMP2.  Whenever  an  event  with  a 
different  time  from  TEMPI  is  encountered,  then  the  resulting  CFS  record  con¬ 
tains  all  the  ADCU-weapon  type  combinations  intercepting  on  that  CFS.  This 

t 
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process  is  continued  until  all  events  on  TEMPI  are  exhausted,  and  all  CFS 
are  thus  established,  for  this  possible  engagement  segment  of  the  flight  path. 
In  case  no  CFS  is  found,  last  event  time  is  set  to  the  end  of  this  possible 
engagement  segment. 

(h)  Setting  Event  to  Call  Section  1  at  Last  Event  Time.  When 
all  events  on  TEMPI  are  processed,  an  event  is  set  in  the  DIVWAG  event  schedul¬ 
ing  system  to  call  Section  1  at  the  time  of  the  last  TEMPI  event.  This  event 
will  begin  generation  of  the  next  possible  engagement  segment  of  the  flight 
leg.  This  pass  through  Section  2  is  now  completed. 

(5)  Section  3  Operating  Details.  Section  3  of  the  In-flight  Attrition 
Submodel  is  the  last  section.  It  calculates  aircraft  losses  incurred  on  a 
single  constant  fire  subsegment  (CFS),  which  was  established  at  an  earlier 
time  in  Section  2.  The  CFS  is  a  relatively  short  segment  of  the  flight  over 
which  projectiles  from  a  unique  set  of  ADCU-weapon  type  combinations  were 
anticipated  to  be  intercepting  the  air  unit.  Section  3  is  called  by  the 
DIVWAG  event-scheduling  system  at  the  end  time  of  the  CFS. 

(a)  Incoming  Data.  Data  accompanying  the  call  to  Section  3 

are  the  same  as  for  Sections  1  and  2,  with  one  exception.  The  call  to  Section 
3  carries  an  additional  item,  which  specifies  where  to  find  the  stored  identi¬ 
ties  of  the  ADCU-weapon  type  combinations  anticipated  to  be  participants  on 
the  CFS.  Section  3  then  obtains  the  additional  information  it  needs.  This 
information  includes  the  unit  status  record  of  the  air  unit,  all  data  stored 
earlier  by  Sections  1  and  2,  a  list  of  all  AD  weapon  types,  the  unit  status 
record  of  each  ADCU  involved  on  this  CFS  ,  suppression  time  durations,  AD 
weapon  characteristics,  and  aircraft  data. 

(b)  Establishing  Coordinates  of  Constant  Fire  Subsegment.  Coor¬ 
dinates  of  the  beginning  and  ending  of  this  CFS  are  established  by  Section  3, 
using  from  stored  data  the  coordinates  of  the  possible  engagement  segment,  the 
start  time  of  the  possible  engagement  segment,  the  speed  of  the  aircraft,  and 
the  start  and  end  times  of  this  CFS.  First,  the  length,  d,  of  the  possible 
engagement  segment  is  calculated  by  the  Pythagorean  theorem.  Next,  the  ending 
time,  tme,  of  the  possible  engagement  segment  is  calculated  by  the  equation: 

tme  *  tmb  +  d/s  (IV-15-31) 

where: 

tmb  *  beginning  time  of  the  possible  engagement  segment 
d  =  length  of  the  possible  engagement  segment 
s  *  speed  of  the  air  unit 
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Then,  the  fraction,  fj.,  of  the  possible  engagement  segment  between  its 
beginning  and  the  beginning  of  the  CFS  is  computed  by  the  formula: 

£1  '=  (tib  "  tnb)  /  <tffie  -  tmb)  (IV-15-32) 

where : 

tfb  =  beginning  time  of  the  CFS 

t^  =»  beginning  time  of  the  possible  engagement  segment 

tjjjg  =  ending  time  of  the  possible  engagement  segment 

The  fraction,  f2,  of  the  possible  engagement  segment  between  its  beginning 
and  the  end  of  the  CFS  is  calculated  by  substituting  the  time  of  the  ending 
in  place  of  time  of  beginning  of  the  CFS  in  the  foregoing  formula.  Using 
these  fractions,  the  coordinates  of  the  CFS  ends  are  calculated  by  the 
equations : 


(IV-15-33) 


(IV-15-34) 


(IV-15-35) 


(IV-15-36) 

where: 

Xb  =  beginning  X  coordinate  of  the  possible  engagement 
segment 

Yb  =  beginning  Y  coordinate  of  the  possible  engagement 
segment 

Xe  ■  ending  X  coordinate  of  the  possible  engagement 
segment 

Yg  ■  ending  Y  coordinate  of  the  possible  engagement 
segment 

f.  ■  fraction  of  possible  engagement  segment  to  start 
of  CFS 


Xib  =  Xb  +  fl  ‘  <Xe  -  xb> 

Yib  "  Yb  +  fX  •  (Ye  -  Yb) 

xie  =  xb  +  f2  '  <xe  "  Xb> 

Yie  =  Yb  +  f2  •  (Ye  -  Yb) 


t 


IV-15-6? 


i’B 


f2  =  fraction  of  possible  engagement  segment  to  end 
of  CFS 

Xfb  =  beginning  X  coordinate  of  the  CFS 
=  beginning  Y  coordinate  of  the  CFS 
Xie  =  ending  X  coordinate  of  the  CFS 
Yie  =  ending  Y  coordinate  of  the  CFS 

(c)  Processing  Each  Participating  ADCU.  More  than  one  ADCU  may 
have  been  anticipated  to  be  a  participant  on  this  CFS.  If  so,  the  ADCUs 
are  processed  one  at  a  time.  This  processing  considers  first  those  factors 
common  to  all  AD  weapon  types  within  an  ADCU.  These  factors  include  AD  sup¬ 
pression  conditions,  the  dispatching  of  escort  aircraft  to  suppress  this 
ADCU,  and  the  geometry  of  the  CFS  as  viewed  from  this  ADCU.  Next,  each 
weapon-type  anticipated  to  be  a  participant,  from  this  ADCU,  is  processed  to 
determine  its  effects  against  the  air  unit. 

1.  AD  Suppression  Check.  To  determine  whether  the  AD  weapons 
in  this  ADCU  were  suppressed  during  any  part  of  this  CFS,  two  sources  of 
suppression  are  considered.  One  source  considered  is  escort  aircraft.  The 
other  source  considered  is  TACAIR  or  ground-based  artillery.  The  most  recent 
interval  during  which  all  AD  weapons  in  the  ADCU  are  assumed  to  be  suppressed 
is  calculated  for  each  of  these  two  sources.  The  two  intervals  are  compared 
with  the  CFS  to  see  if  overlap  occurs.  If  overlap  does  occur,  the  fraction 
of  the  CFS  overlapped  is  calculated  for  later  use.  If  the  CFS  is  totally 
overlapped,  the  ADCU  is  considered  not  to  be  firing. 

a.  AD  Suppression  by  TACAIR  or  Ground  Artillery.  To 
establish  the  most  recent  interval  for  AD  suppression  by  TACAIR  or  ground- 
based  artillery,  the  time  of  last  assessment  by  the  Area  Fire  Model  is 
obtained  from  the  unit  status  record  of  the  ADCU.  This  time  is  considered 
to  be  the  start  of  the  suppression  interval.  Next,  an  input  ADCU  suppression 
time  duration  is  obtained  from  the  suppression  time  tables  (see  Chapter  11) , 
for  each  of  TACAIR  and  artillery,  according  to  the  unit  type  (UTD) ,  of  the 
ADCU.  These  two  input  values  are  averaged  and  added  to  the  start  of  the 
suppression  interval  to  yield  the  end  of  the  suppression  interval  for  TACAIR 
or  ground-based  artillery. 

b_.  AD  Suppression  by  Escorts.  Each  time  an  escort  pair 
is  dispatched,  as  described  below,  to  suppress  an  ADCU,  an  input  ADCU  sup¬ 
pression  time  duration  is  applied.  This  time  duration  is  obtained  from  the 
same  suppression  time  tables  referenced  in  the  preceding  subparagraph.  In 
the  case  of  escorts,  however,  this  suppression  time  duration  is  applied  at 
the  time  of  escort  dispatch,  to  generate  a  time  at  which  escort  suppression 
of  the  ADCU  will  lapse,  te,  by  the  expression: 
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te  =  cb  +  ts  +  cm 


(1V-15-37) 


where : 


tk  =  time  at  which  suppression  will  begin 

ts  =  suppression  time  duration  -  input  (suppression  tables) 
tjjj  =  suppression  mission  duration  -  input  for  In-Flight  Attrition 
The  time  at  which  suppression  will  begin,  tb,  is  further  defined  as: 


tb  =  td  +  tr  (IV-15-38) 

where : 

t^  *  time  of  of  escort  pair  dispatch  to  suppress  ADCU 

tr  =  response  time  of  escorts  to  reach  and  attack 
ADCU  -  input  for  In-flight  Attrition 

The  times  at  which  escort  suppression  will  lapse,  te,  and  start,  tb,  are 
stored  on  the  unit  status  file  of  the  ADCU;  therefore,  when  Section  3 
seeks  to  check  the  most  recent  interval  for  escort  suppression,  these  two 
values  are  obtained  from  the  ADCU  unit  status  record. 

£.  Joint  Suppression.  The  combined  suppression  for 
escorts  and  for  TACAIR  or  ground-based  artillery  is  formed  through  several 
logic  steps.  The  simplest  case  is  where  the  suppression  interval  for  TACAIR 
or  ground-based  artillery  overlaps  the  suppression  interval  for  escorts. 

In  this  case,  a  joint  suppression  interval  can  be  formed,  consisting  of  the 
earliest  of  the  two  interval  starts  and  the  latest  of  the  two  interval  ends. 
This  joint  interval  is  then  rectified  (truncated,  if  necessary)  so  that  only 
that  portion  which  overlaps  the  CFS  is  considered  further.  The  fraction,  f, 
of  the  CFS  overlapped  by  the  joint  suppression  interval  is  chen  calculated 
by  the  expression: 


f  -  (tse  -  tsb)  /  (tle  -  tib)  (IV-15-39) 

where: 

tge  *  rectified  ending  time  of  joint  suppression  interval 
tsb  *  rectified  beginning  time  of  joint  suppression  interval 
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tie  =  ending  time  of  CFS 
cib  =  beginning  time  of  CFS 

If,  however,  the  suppression  interval  for  TACAIR  or  ground-based  artillery 
does  not  overlap  the  suppression  interval  for  escorts,  further  logic  steps 
are  necessary.  Each  interval  is  compared  with  the  CFS  to  see  if  any  overlap 
occurs.  If  neither  interval  has  any  overlap,  the  fraction,  f,  is  set  to 
zero.  If  one  interval  has  overlap,  but  the  other  does  not,  the  former 
interval  is  rectified  and  used  in  the  same  way  as  in  the  simplest  case  to 
calculate  the  overlap  fraction,  f.  If  both  intervals  have  some  overlap, 
each  interval  is  independently  rectified  and  its  overlap  fraction  calculated 
as  described  above.  The  two  fractions  are  then  summed  to  yield  the  joint 
overlap  fraction.  The  joint  overlap  fraction  is  used  in  the  suppression 
check  (next  subparagraph)  and  also  later  in  calculating  the  number  of  weapons 
able  to  fire. 


<1.  Suppression  Check.  If  the  joint  suppression  overlap 
fraction  is  1.0,  no  AD  weapons  in  this  ADCU  are  considered  to  fire  during 
this  CFS;  therefore,  since  the  ADCU  is  not  firing  AD  weapons,  escorts  will 
not  be  dispatched  to  suppress  it,  and  the  ADCU  is  not  processed  further  on 
this  CFS. 


2_.  Decision  to  Dispatch  Escorts.  If  the  ADCU  is  firing, 
several  checks  are  made  to  determine  whether  a  pair  of  escort  aircraft  should 
be  dispatched  to  suppress  the  ADCU. 

a.  Has  Air  Unit  Passed  Beyond  No  Request  Point?  If 
at  the  beginning  of  the  CFS  the  air  unit  has  passed  beyond  the  "no  request 
point,"  escorts  are  not  dispatched.  Whether  the  air  unit  has  passed  beyond 
the  "no  request  point"  is  determined  with  the  help  of  utility  routine  PONTLN. 
This  routine  is  given  the  X,Y  coordinates  of  the  beginning  and  ending  of 
this  possible  engagement  segment  of  the  flight  path  and  the  X,Y  coordinates 
of  the  ADCU.  PONTLN  returns  a  value,  T^  which  represents  the  position  of 
the  ADCU  along  the  flight  path  relative  to  the  beginning  and  ending  of  the 
segment.  The  value  of  T^  returned  is  negative  if  the  ADCU  is  off  the  begin¬ 
ning.  Between  the  beginning  and  ending  of  the  segment,  the  value  of  Tj 
varies  from  zero  to  1.0,  representing  the  fractional  position  of  the  ADCU 
along  the  segment.  Beyond  the  ending,  the  value  of  T^  increases  in  the  posi¬ 
tive  direction.  The  "no  request  point,"  meanwhile,  is  based  on  the  beginning 
of  CFS.  For  comparison  with  T^,  a  value,  T2*  representing  the  position  of 
the  "no  request  point"  is  generated  by  the  expression: 

t2  “  <cib  *  tab  '  c)  /  (d/s)  (IV-15-40) 
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where: 


cib  *  beginning  time  of  the  CFS 

tjjjj  =  beginning  time  of  the  possible  engagement  segment 

t  «  the  length  of  time  after  passing  the  ADCU  beyond 

which  escorts  would  not  be  sent  back  to  suppress 
it,  from  input  data 

d  »  the  length  of  the  possible  engagement  segment 
s  »  speed  of  the  air  unit 

The  two  values  are  now  compared,  and  if  T2>T^,  the  air  unit  is  considered 
beyond  the  "no  request  point,"  and  escorts  are  not  dispatched. 

b..  Is  ADCU  Too  Far  Away  From  Flight  Path?  If  the  ADCU 
is  located  at  a  distance  from  the  flight  path  which  exceeds  the  maximum  dis¬ 
tance  which  escorts  are  permitted  to  direct  to  attack  plus  any  stand-off  dis¬ 
tance  of  the  escort  munition  to  be  employed,  escorts  are  not  dispatched  to 
suppress  this  ADCU.  The  distance  from  the  ADCU  perpendicular  to  the  flight 
path  is  another  value  returned  by  utility  routine  PONTLN,  just  employed 
as  described  in  the  preceding  subparagraph.  The  distance  which  escorts  are 
permitted  to  direct  plus  their  munition  standoff  distance  are  combined  in 
a  single  input  value,  used  in  this  comparison. 

£.  Are  Escorts  Available?  If  a  pair  of  escorts  does  not 
remain  on  hand,  according  to  the  unit  status  record  of  the  air  unit,  escorts 
are  not  dispatched.  If  escorts  are  dispatched,  no  adjustment  is  currently 
made  to  the  number  available. 

<i.  Dispatch  of  Escorts.  If  the  three  preceding  questions 
are  all  answered  positively,  a  pair  of  escorts  is  considered  dispatched  to 
suppress  the  firing  ADCU.  The  suppressive  effect  of  this  attack  by' escorts 
is  recorded  on  the  unit  status  record  of  the  ADCU,  as  described  in  paragraph 
lb,  above. 

3_.  Geometry  to  Mid  Point  of  CFS: 

£.  Mid  Point  of  the  CFS.  The  mid  point  of  the  CFS  is 
established  using  the  coordinates  of  the  beginning  and  ending  of  the  CFS  as 
calculated  at  the  beginning  of  Section  3.  The  X  and  Y  coordinates  of  the 
mid  point  are  each  calculated  as  one-half  the  sum  of  the  corresponding  begin¬ 
ning  and  ending  coordinates  of  the  CFS.  The  Z  coordinate  of  the  mid  point  is 
then  obtained  for  the  X,Y  coordinate  by  use  of  the  routine  ELEVAT. 
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b_.  Aspect  Angles  and  Slant  Range.  Both  the  horizontal 
and  vertical  angles  from  the  ADCU  to  the  air  unit  are  calculated.  The 
horizontal  aspect  angle  has  its  apex  at  the  ADCU  and  is  measured  between 
the  point  on  the  flight  path  nearest  the  ADCU  (the  crossover  point)  and  the 
air  unit.  The  vertical  aspect  angle  similarly  has  its  apex  at  the  ADCU  and 
is  measured  between  the  air  unit  and  the  X,Y  plane  containing  the  ADCU. 

To  calculate  the  horizontal  aspect  angle,  the  ground  track  (in  the  X,Y  plane 
of  the  ADCU)  of  the  flight  path  is  used.  The  horizontal  distance,  dm,  from 
the  ADCU  to  the  mid  point  of  the  CFS  is  computed  by  the  expression: 

dm  -  ^(Xim  -  Xa)2  +  (Yim  -  Ya) 2  (IV-15-41) 

where: 

Xim  =  X  coordinate  of  midpoint  of  CFS 
Yim  ■  Y  coordinate  of  midpoint  of  CFS 
Xa  =  X  coordinate  of  ADCU  center 
Ya  =  Y  coordinate  of  ADCU  center 

The  horizontal  distance,  dc,  from  the  ADCU  to  the  crossover  point  is  obtained 
by  use  of  the  utility  routine  DISTPL,  which  is  given  the  beginning  and  ending 
X,Y  coordinates  of  the  CFS  and  the  X,Y  coordinates  of  the  ADCU.  The 
horizontal  aspect  angle,  H,  is  then: 


where: 


H  *  sin 


(dc/dm) 


(TV- 1.5-42) 


dc  «  horizontal  distance  from  ADCU  to  crossover 
point,  defined  above 

dm  =  horizontal  distance  from  ADCU  to  air  unit 
point,  defined  above 

To  calculate  the  vertical  angle,  V,  the  Z  coordinate  of  the  ADCU  is  obtained, 
through  the  routine  ELEVAT,  given  the  X,Y  coordinates  of  the  ADCU.  For  use 
here  and  also  in  later  steps,  the  slant  range,  rs,  from  the  ADCU  to  the  mid 
point  of  the  CFS  is  calculated  by  the  expression: 


r 


s 


(IV-15-43) 
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where : 


dm  ■  as  defined  above 

h  =  difference  in  Z  coordinates  of  ADCU  and 
mid  point  of  CFS 

The  vertical  aspect  angle,  V,  is  then: 

V  =  sin  (h/rs) 


(IV-15-44) 


where : 


h  =  as  defined  above 

rs  =  slant  range,  as  defined  above 

£.  Angular  Rates  of  Air  Unit.  The  rates  of  change  in 
the  horizontal  and  vertical  angles  from  the  ADCU  to  the  air  unit  are 
calculated  for  comparison  with  the  slew  rate  or  tracking  rate  capability  of 
AD  weapons.  The  horizontal  angular  rate,  Hr,  is  calculated  by  the  expression 


Hr  -  s*cosine  (H)/dm  (IV-15-45) 

where: 

s  *  speed  of  the  air  unit 

dm  ■  horizontal  distance  from  ADCU  to  mid  point  of  CFS 
cosine(H)  ■  ^  l-sine^(H) 

The  vertical  angular  rate,  Vr  ,  is  computed  by  the  similar  equation: 

Vr  *  s-sine(V)/rs  (IV-15-46) 

where: 

s  “  speed  of  air  unit 
ra  *  slant  range 
sine(v)  ■  as  defined  above 
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ci.  Aircraft  Direction.  Also  relative  to  the  mid  point 
of  the  CFS,  a  determination  is  made  as  to  whether  the  aircraft  are  approaching 
or  leaving  the  ADCU.  This  determination  is  made  with  the  help  of  routine 
PONTLN,  which  is  given  the  X,Y  coordinates  of  the  mid  point  and  the  ending 
of  the  CFS  and  the  X,Y  coordinates  of  the  ADCU.  If  the  value  of  the  variable 
returned  which  relates  the  position  of  the  ADCU  to  this  line  segment  is  nega¬ 
tive,  the  aircraft  are  leaving;  otherwise  they  are  approaching. 

Presented  Area  of  Each  Aircraft  Type.  For  each  type 
of  aircraft  in  the  air  unit,  the  area  of  one  aircraft,  as  presented  to  the 
ADCU,  is  calculated  for  the  mid  point  of  the  CFS.  Input  data  provides  the 
face-perpendicular  areas  of  the  front  or  rear,  side,  and  bottom  of  each  air¬ 
craft  type.  The  area,  Ap,  presented  to  the  ADCU,  from  the  mid  point,  for  a 
given  aircraft  type,  is  calculated  by  the  equation: 


Ap  =  A^  •  cosine(V)  •  sine(H)  +  A2  *  cosine(V) 
•  cosine(H)  +  A3  •  sine(V) 


(IV-15-47) 


where: 


A^  =  area  of  front  or  rear 
A2  *  area  of  side 
A3  ■  area  of  bottom 

sines  and  cosines  of  angles  are  as  defined  above 
or  derived  therefrom 

f_.  Fraction  of  ADCU  in  Line  of  Sight.  To  determine  the 
fraction  of  the  ADCU  (and  its  contained  AD  weapons)  which  have  line  of  sight  J 

to  the  air  unit  on  this  CFS,  a  method  is  used  which  should  provide  approximate  ^ 

answers  of  the  right  magnitude.  This  method  was  developed  for  this  model, 
without  benefit  of  empirical  data,  and  should  be  considered  an  interim  method. 

To  apply  this  method,  the  terrain  cell  containing  the  ADCU  is  identified, 

and  the  corresponding  values  of  the  terrain  indexes,  roughness-vegetation,  and 

forestation,  are  obtained.  The  environment  routine  IOTERN  is  given  the  X  and  • 

Y  coordinates  of  the  ADCU  to  provide  these  values.  Next,  the  vertical  angle 

from  the  ADCU  to  the  air  unit,  defined  above,  is  calculated  in  degrees  by  t 

the  expression: 


V<j  -  tan-1  (sine(V) / cosine (V) )  •  57.3  (IV-15-48) 

If  the  vertical  angle,  Vd,  is  greater  than  45  degrees,  the  fraction,  fios, 
of  the  ADCU  in  line  of  sight  is  calculated  by  the  formula: 
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1.05  -  0.05  •  RV 


(IV-15-49) 
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where: 


RV  ■  roughness-vegetation  index,  with  values  ranging  from 
1-9  (see  Chapter  4) 

If  the  vertical  angle  is  less  than  or  equal  to  45  degrees,  the  fraction  in 
line  of  sight  is  computed  by  the  formula: 


f los  =  0.55  +  0.05(1  +  Vd/5  )  -  0.05-  RV 


(IV-15-50) 


where: 


RV  ■  as  defined  above 
Vd  *  as  defined  above 

Finally,  in  either  case,  if  the  terrain  cell  is  forested  (i.e.,  if  the 
forestation  index  value  is  greater  than  zero),  three  fourths  of  the  fraction 
calculated  above  is  taken  for  the  fraction  of  the  ADCU  in  line  of  sight  to 
the  air  unit. 

(d)  Processing  Each  Participating  Weapon  Type  in  the  ADCU. 

Within  each  ADCU  which  passes  the  foregoing  tests,  each  AD  weapon  type  anti¬ 
cipated  to  be  a  participant  on  this  CFS  is  processed  to  determine  its  possible 
effects  against  the  air  unit.  This  processing  includes  rechecking  for  weapons 
on  hand,  checking  the  air  unit  angular  rate  against  weapon  slew  rate,  and 
determining  the  fraction  of  the  ADCU  in  range  of  the  air  unit,  with  subsequent 
separate  processing  of  missile  weapons,  as  distinguished  from  gun  weapons. 

1^.  Check  for  Weapons  on  Hand.  The  number  of  weapons  on  hand 
of  this  type  is  obtained  from  the  current  unit  status  record  of  the  ADCU.  If 
no  weapons  remain,  this  weapon  type  is  not  considered  further,  and  the  next 
weapon  type  is  considered. 

2.  Slew  Rates  Check.  If  weapons  are  on  hand,  the  angular 
rates  of  the  air  unit  are  compared  with  the  maximum  slew  rates  of  the  weapon 
type,  from  the  Input  data.  If  the  rate  of  change  of  either  the  horizontal 
or  vertical  angle  from  the  ADCU  to  the  air  unit,  as  calculated  earlier, 
exceeds  the  respective  maximum  slew  rate  of  the  weapon,  this  weapon  type  is 
not  considered  further. 

Fraction  of  ADCU  in  Degraded  Range.  To  determine  the 
fraction  of  the  ADCU  weapons  of  this  type  which  are  within  range  of  the  mid 
point  of  the  CFS,  the  maximum  effective  range  of  the  weapon,  from  input,  is 
adjusted  for  any  degradation  which  may  be  caused  by  current  weather-visibility 
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conditions,  as  expressed  by  the  DIVWAG  visibility  index,  of  which  the  value 
varies  from  1  to  9  (see  Chapter  4).  Input  data  for  the  weapon  provides  capa¬ 
bility  degradation  percentages  for  five  categories  of  weather-visibility  index, 
WV.  These  categories  are  defined  as  very  poor  (WV  =  1-2),  poor  (WV  =3-4), 
intermediate  (WV  =  5-6),  fair  (WV  =  7-8),  and  good  (WV  *  9).  The  respective 
degradation  percentage,  dp,  is  applied  to  the  maximum  effective  range,  rm,  of 
the  weapon  to  obtain  adjusted  effective  range,  ra,  by  the  expression: 


ra  =  rm  <1  ~dp> 


(IV-15-51) 


The  Z  coordinate  of  the  ADCU  is  obtained  by  routine  ELEVAT,  which  is  given 
the  X,Y  coordinates.  The  radius  of  the  circle  on  whose  circumference  the 
AD  weapons  are  assumed  to  be  uniformly  distributed  is  calculated  as  one-half 
the  lesser  of  ADCU  width  or  depth.  The  X,Y,Z  coordinates  of  the  ADCU  and  the 
radius  of  weapon  location  in  the  ADCU  is  given  to  geometric  routine  CIRCLE, 
together  with  the  X,Y,Z  coordinates  of  the  mid  point  of  the  CFS  and  the 
adjusted  effective  range  of  the  weapon.  CIRCLE  returns  the  fraction  of  the 
weapon  location  circle  which  lies  within  a  slant  distance,  ra,  of  the  mid 
point  of  the  CFS.  If  this  fraction  is  zero,  this  weapon  tyr>e  is  not  considered 
further. 


4,.  Net  Number  of  Weapons  Intercepting.  This  processing  step 
combines  a  number  of  factors  generated  in  prior  steps  with  system  reliability 
and  electronic  countermeasures  (ECM)  degradation  factors  to  yield  the  net  number 
of  weapons  intercepting  on  this  CFS.  This  processing  is  based  upon  the  gross 
number  of  weapons  of  this  type  on  hand  in  this  ADCU  at  the  time  of  the  last 
inventory.  The  model  currently  takes  the  last  inventory  at  the  end  of  the  CFS, 
although  ideally  the  inventory  should  be  taken  at  the  beginning  of  the  CFS  and 
losses  during  the  segment  prorated.  The  various  factors  are  applied  to  this 
gross  number  to  yield  the  net  number,  according  to  the  equation: 

wn  -  wg  •  (l-fd)  •  (1-f s) • f los ' fr ' R' (1— f e)  (IV-15-52) 

where: 

Wn  ■  net  number  of  weapons  intercepting 

Wg  *  gross  number  of  weapons  on  hand  at  last  inventory 

fd  »  fraction  of  weapons  destroyed  since  last 
inventory  (currently  set=0) 

fs  *  fraction  of  weapons  suppressed  during  the  CFS 
as  defined  in  subparagraph  (c)L:,  above 
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f^os  “  fraction  of  weapons  in  line  of  sight,  as 
defined  in  subparagraph  (c)3f,  above 

fr  =  fraction  of  weapons  in  degraded  range,  as 
defined  in  subparagraph  (d)3^  above 

R  =  system  reliability  factor,  from  input 

fe  =  ECM  degradation  percentage,  from  input 

If  the  net  number  of  weapons  intercepting  is  less  than  0.5,  this  weapon 
type  is  not  considered  further. 

(e)  Further  Processing  of  Missile  Weapons.  If  a  missile  weapon 
type  passes  the  foregoing  tests,  the  probability  of  kill  values,  for  a 
single  missile,  are  linearly  interpolated  from  an  input  table  for  this 
missile  type,  according  to  a  calculated  missile  miss  distance  against  a 
single  aircraft.  The  four  categories  of  kill,  as  defined  above,  are  con¬ 
sidered.  Each  of  the  net  number  of  weapon  systems,  as  defined  in  the  pre¬ 
ceding  subparagraph,  is  assumed  to  fire  one  missile.  Refinement  of  this 
assumption,  through  consideration  of  rate  of  fire  limitations,  may  be  added 
at  a  later  date.  The  number  of  missiles  fired  is  then  multiplied  by  the 
probability  of  kill  values  to  yield  losses.  The  assumption  is  made  that 
each  missile  Is  directed  at  a  single  aircraft,  and  that  a  relatively  few 
missiles  are  fired  from  this  ADCU  on  this  CFS.  Missiles  fired  are  subtracted 
from  the  unit  status  record  of  the  ADCU. 

1^.  Calculation  of  Miss  Distance.  The  model  currently  uses 
as  input  an  average  missile  guidance  error  for  this  weapon  type.  It  is 
assumed  that  errors  in  both  dimensions  are  equal  and  independent;  therefore, 
the  standard  deviation  of  the  error,  for  a  Rayleigh  distribution,  is  given 
by  the  formula: 

e 

(IV-15-53) 


where: 


s  ■  one  standard  deviation 
a  »  average  error 

A  distance  is  then  selected  from  a  normal  distribution  by  the  expression: 


d  -  S  '  F(R  ) 
n 


(IV-15-54) 
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where : 


S  =  as  defined  above 
Rn  =  a  random  number  between  0  and  1. 

F  =  a  function  which  returns  the  position  on 

the  normal  curve,  in  standard  deviations, 
corresponding  to  the  cumulative  area 
represented  by  the  random  number  (utility 
routine  FNORM) . 

The  distance  selected  is  then  adjusted  to  miss  distance  by  subtracting  a 
radius  extracted  from  the  presented  area  of  the  aircraft  fired  upon. 

2.  Aircraft  Losses.  Based  on  the  calculated  miss  distance, 
probability  of  kill  values  for  one  missile  against  one  aircraft  are  linearly 
interpolated  from  input  for  the  type  of  aircraft  attacked.  The  type  attacked 
is  assumed  to  be  the  type  having  the  largest  presented  area  in  the  air  unit. 
Losses  for  each  of  the  four  kill  type  categories  are,  tentatively,  the 
product  of  interpolated  probability  of  kill  and  number  of  missiles  fired,  as 
defined  above.  Later  integration  of  these  values  with  gun  effects  limits 
these  loss  values  to  the  number  of  aircraft  on  hand  of  that  type. 

(f)  Further  Processing  of  Gun  Weapons.  If  a  gun  weapon  type 
passes  the  tests  up  to  this  point,  it  is  processed  further  to  yield  probability 
of  kill  values  and  to  combine  these  values  with  the  values  of  other  gun  systems 
in  the  form  of  cumulative  or  compound  probabilities  of  survival  of  a  single 
aircraft  to  gun  systems.  This  processing  includes  calculation  of  the  number  of 
rounds  intercepting  the  air  unit,  the  number  of  rounds  per  aircraft,  the  vul¬ 
nerable  areas  of  the  aircraft  at  the  aspect  angles  and  projectile  striking 
velocity  of  the  mid  point  of  the  CFS,  estimation  of  gun  weapon  errors  and  prob¬ 
able  hits,  and  finally  the  determination  of  probabilities  of  kill  and  compound 
probabilities  of  survival  for  each  of  the  four  kill  categories. 

JL.  Number  of  Rounds  Intercepting  Air  Unit.  The  number  of 
rounds  from  this  weapon  type,  in  this  ADCU,  that  will  intercept  the  air  unit 
is  based  on  the  net  number  of  weapons,  defined  above,  and  the  rate  of  fire  and 
possible  reload  delays  that  may  occur  on  this  CFS.  First,  an  average  rate  of 
fire,  without  reload  delay,  is  calculated  by  the  formula: 


R 


(IV-15-55) 
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where: 


R  =  average  rate  of  fire,  without  reload  delay,  for  one  weapon 

bn  =  number  of  rounds  per  burst,  from  input  for  this  weapon  type 

br  =  cyclic  rate  of  fire,  rounds  per  unit  time,  from  input 

bjj  =  delay  time  between  bursts,  from  input. 

Next,  the  time  required  to  exhaust  magazine  capacity  at  the  above  rate  is 
calculated  by  the  expression: 


t 


mag 


C/R 
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where: 

tmag  “  ti®6  to  exhaust  magazine  capacity  at  rate  R 
C  ■  capacity  of  magazine,  in  rounds,  from  input 
R  *  rate,  as  defined  above. 

the  number  of  reloads  required,  Nre,  is  calculated  by  the  equation: 


"re 


=  t 


is 


j{^  mag  +  crej 


(IV-15-57) 


where : 

tis  *  time  length  of  the  CFS 

tmag  *  tiroe  to  exhaust  magazine  capacity,  as  defined  above 
tre  *  reload  delay,  from  input 

Firing  time  at  average  rate  without  reloads,  tfa,  is  calculated  by  the 
expression: 

cfa  -  tls  -  Nre-tre  (IV- 15-58) 

where : 

tis  *  as  defined  above 

Nre  *  number  of  reloads  require'’,  is  defined  above 
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The  number  of  rounds,  N,  intercepting  the  air  unit  is  then  calculated  by  the 
equation : 


N  =  R-tfa-Wn 


(IV-15-59) 


where : 


R  =  average  rate  of  fire  without  reload,  as  defined  above 

tfa  =  firing  time  at  average  rate  without  reload,  as  defined  above 

Wn  =  net  number  of  weapons  intercepting 

The  number  of  rounds,  N,  is  then  limited  to  the  number  of  rounds  of  ammunition 
on  hand  of  this  type  in  this  ADCU,  as  obtained  from  the  ADCU  unit  status  record. 
This  same  number  of  rounds  is  also  subtracted  from  the  unit  status  record  to 
represent  ammunition  expenditures. 

2.  Number  of  Rounds  Per  Aircraft.  For  guns,  it  is  assumed 
that  the  rounds  intercepting  are  equally  distributed  over  the  number  of  air¬ 
craft  of  all  types  in  the  air  unit  at  the  start  of  the  CFS.  The  number  of 
rounds  intercepting  per  aircraft,  Na,  is  then: 

Na  -  N/A  (IV-15-60) 


wnere : 


N  =  number  of  rounds  intercepting  air  unit,  as  defined  above 
A  ■  number  of  aircraft  of  all  types  in  the  air  unit. 

_3.  Vulnerable  Areas  of  Aircraft.  Aircraft  vulnerable  area 
data  are  basic  input  for  calculation  of  gun  weapon  type  probabilities  of  kill. 
Currently,  Section  3  uses  as  input  the  same  average  vulnerable  area  data  as 
used  by  the  ENRATA  portion  of  the  Air  Ground  Engagement  Model.  These  data 
comprise  a  single  vulnerable  area  value  for  each  of  four  kill  categories, 
within  each  weapon  type-aircraft  type  combination.  Since  the  values  for  the 
four  kill  categories  are  embedded  one  within  another  in  a  cumulative  fashion, 
the  individual  values  must  be  extracted  before  use  in  Section  3.  These  data 
are  averages,  assuming  an  average  aspect  angle  and  an  average  slant  range. 
Section  3  is  designed,  however,  to  utilize,  at  some  later  date,  detailed 
vulnerable  area  data  tables.  Such  tables  contain  data  for  seven  striking 
velocities  and  for  each  of  the  faces  of  the  aircraft  (front,  rear,  top,  bottom, 
and  side).  To  interpolate  vulnerable  area  data  from  such  tables,  at  some  later 
date,  striking  velocity  against  a  stationary  target,  Vst,  is  calculated  by  the 
formula: 

vst  "  vm/6-  +fd‘cf)2  (IV-15-61) 
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where : 


Vm  *  muzzle  velocity  of  the  weapon,  from  input 
fj  «*  ballistic  drag  coefficient,  from  input 

tj  =  time  of  flight  of  projectile,  calculated  as  described  in  Section  2 

Striking  velocity  against  the  moving  target,  Vmt,  is  then  derived  from  the 
stationary  situation  by  the  formula: 


vmt 


*  Vst  +  f-sine(H)- cosine  (V)-s  (IV-15-62) 


where: 


V  t  =  as  defined  above 

f  *  either  minus  1  or  plus  1,  depending  on  aircraft  direction 

H  =  horizontal  aspect  angle,  as  defined  above 

V  =  vertical  aspect  angle,  as  defined  above 

At  some  later  date,  interpolated  vulnerable  areas  of  each  face  can  be  con¬ 
solidated  into  one  area,  using  the  expression: 


A  *  Avf 'cosine(V) "sineOO+Ayj 'cosine(V) 'sine(H) 
+AVS  ■  cosine  (V)  •  cosine  (H)+AV]J  •  sine  (V) 


(IV-15-63) 


where : 


Avf  -  front  vulnerable  area  (zero  if  aircraft  leaving) 
kWY  ■  rear  vulnerable  area  (zero  if  aircraft  approaching) 

Ayg  *  side  vulnerable  area 
Av()  *  bottom  vulnerable  area 

Weapon  Error.  Four  separate  sets  of  equations,  from  the 
AM/HI  study,  are  used  to  approximate  the  weapon  error  associated  with  four  types 
of  gun  system.  These  four  types  of  system  are,  (1)  visually  sighted  12.7mm 
or  .50  cal  mg,  (2)  optically  directed  14.5mm,  23mm,  and  57mm  systems,  (3) 
range-only  radar  systems,  and  (4)  full-solution  radar  systems.  These  equations 


6.  Reference  6;  Annex  F,  pp.  F-19,  F-20,  F-21-and  F-46. 
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account  for  aiming  errors  and  ballistic  dispersion  errors.  Parameters  used  by 
these  equations  include  slant  range,  as  defined  above,  aircraft  speed,  target 
angular  rate,  and  projectile  time  of  flight,  as  defined  above.  Target  angular 
rate  is  taken  here  to  be  the  maximum  of  the  horizontal  or  vertical  rates,  as 
defined  above.  An  item  in  the  weapon  input  data  designates  which  equation  set 
is  used.  The  result  of  these  equations  is  a  standard  deviation  in  square 
meters.  On  an  experimental  basis  another  equation,  from  the  ADAFSS  study,  is 
used  to  approximate  target  maneuver  error.  This  equation  uses  aircraft  speed, 
projectile  time  of  flight,  and  a  data  input  representing  an  average  evasive 
maneuver  turn  acceleration  rate.  This  equation  also  yields  a  standard  devia¬ 
tion  in  square  meters.  Total  error  standard  deviation  used  for  hit  calcula¬ 
tions,  is  then  the  square  root  of  the  sum  of  the  squares  of  the  components  in 
square  meters. 


from  the  gun  weapon 


Probability  of  Hit. 
type  is  calculated  by 


Phi 


1  -e"Ap/(2,r-E2) 


The  probability  of  hit 
the  equation: 


by  one  round 


(IV-15-64) 


where : 

Phi  ”  probability  of  hit  by  one  round  against  this  aircraft  type 

Ap  **  presented  area  of  this  aircraft  type,  as  defined  above 

E  *  total  weapon  error,  in  square  meters 

The  probability  of  hit  is  calculated  against  each  type  of  aircraft  in  the 
air  unit. 

6..  Probability  of  Kill.  Probability  of  kill  by  one  round 
from  the  weapon  type  is  calculated  by  the  expression: 


where: 


(IV-15-65) 


pkl  *  probability  of  kill,  this  kill  category,  this  aircraft  type,  by 
one  round 


phl  *  probability  of  hit,  as  defined  above 

Ay  ■  vulnerable  area  of  this  aircraft  type  to  this  weapon,  as  defined 
above 


7.  Reference  26,  p.  4  and  addendum. 
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Ap  =  presented  area  of  this  aircraft  type,  as  defined  above. 


The  probability  of  kill  by  the  number  of  rounds  per  aircraft  is  evaluated  by 
the  expression: 


pkna 


Na 

1  -  (1  -  Pkl) 


(IV- 15-66) 


where: 


pkna  =  probability  of  kill,  this  kill  category,  this  aircraft  type,  by 
number  of  rounds  per  aircraft 

Pki  =  probability  of  kill  by  one  round,  as  defined  above 
Na  =  number  of  rounds  per  aircraft,  as  defined  above 

Compound  Probability  of  Survival.  The  probabilities  of 
survival  are  compounded,  for  each  gun  weapon  type  intercepting,  as  each  gun 
weapon  type  is  processed.  These  compound  probabilities  of  survival,  for  each 
kill  category  and  each  aircraft  type  in  the  air  unit,  are  for  use  in  the  final 
loss  calculations.  The  compound  probabilities  of  survival,  starting  with  a 
value  of  1.0,  are  calculated  by  the  expression: 


Psp  =  1  -  n  (1  -  Pkna)  (IV-15-67) 

all  gun 
types 


where: 

Pgp  «  compound  probability  of  survival,  this  aircraft  type,  this  kill 
category,  to  date 

P^a  “  probability  of  kill,  as  defined  above. 

(g)  Final  Loss  Calculations.  Final  loss  calculations  combine 
missile  effects  and  gun  effects.  Aircraft  losses  to  missiles,  as  described 
in  subparagraph  (e)  above,  and  limited  to  the  number  of  aircraft  on  hand 
of  the  type  attacked,  are  subtracted  from  the  aircraft  on  hand  in  the  air 
unit,  before  gun  losses  are  calculated.  Losses  to  guns  are  then  computed  by 
applying  the  probabilities  of  survival,  compounded  over  all  intercepting  gun 
weapon  types,  to  the  remaining  aircraft  of  each  type.  Gun  losses  are  computed 
by  Che  equation: 


L  -  A  •  (1  -  Psp) 


(IV-15-68) 


t 
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where: 


A  =  number  of  aircraft  remaining  on  hand  of  this  type,  after  prior 
kill  subtraction 

PSp  =  compound  probability  of  survival,  this  aircraft  type,  this  kill 
category,  as  defined  above 

Troop  and  cargo  losses  are  subtracted  from  the  air  unit  in  proportion  to 
A  and  B  kills. 
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APPENDIX  A 


AIRMOBILE  MODEL  INPUT  REQUIREMENTS 


1.  INTRODUCTION.  The  Airmobile  Model  simulates  the  execution  of  an  airmobile 
operation,  including  the  staging  and  loading  of  aircraft;  the  airmobile 
assault  to  an  objective  area;  the  attrition  of  aircraft  in  flight  to  and  from 
the  objective  area;  the  rearm  and  refuel  of  the  aircraft;  and  the  release  of 
the  aircraft  after  the  airmobile  assault  is  completed. 

a.  This  appendix  provides  instructions  for  entering  constant  data  into 
the  model  files  prior  to  commencement  of  game  play.  Only  the  unique  data 
elements  that  are  constant  throughout  the  play  of  the  game  and  are  applicable 
to  the  operation  of  this  model  are  included  herein.  Other  data  are  necessary 
for  the  operation  of  the  Airmobile  Model;  these  are  defined  and  developed  as 
constant  data  for  other  models  and  are  indicated  in  paragraph  2  below. 

b.  The  relative  position  of  this  chapter  is  arbitrary  and  does  not 
represent  the  priority  with  which  data  must  be  entered  in  the  constant  data 
base.  All  DIVWAG  system  data  must  be  loaded  prior  to  game  time,  and  first 
priority  is  accorded  to  TOE  load. 

2.  DATA  INPUT  BY  OTHER  LOAD  PROGRAMS; 

a.  Weight  and  Volume  Capacity  of  Transport  Aircraft.  The  weight  and 
volume  capacities  of  the  transport  aircraft  are  used  in  determining  the  number 
of  aircraft  and/or  trips  required  to  airlift  a  given  unit  during  an  airmobile 
operation.  These  values  are  loaded  by  the  Combat  Service  Support  Model  load 
program  (see  Chapter  16  of  this  section)  which  stores  them  on  data  file  11. 

b.  Weight  and  Volume  of  Transported  Items,  The  weight  and.  volume  of 
the  items  to  be  transported  are  also  used  in  determining  the  number  of  air¬ 
craft  and/or  trips  required  to  airlift  a  unit  during  an  airmobile  operation. 
The  weight  and  volume  by  equipment  item  code  are  loaded  by  the  Combat  Service 
Support  Model  load  program  on  to  data  file  11. 

c.  Aircraft  Fuel  Consumption,  The  aircraft  fuel  consumption  rates 
which  are  used  by  the  Airmobile  Model  are  obtained  from  File  14.  The  Move¬ 
ment  Model  load  program  (Chapter  13)  loads  these  rates. 

d.  Aircraft  Characteristics.  Several  aircraft  characteristics  are  used 
by  the  Airmobile  Model.  These  include  speed,  landing  times,  and  mission 
availability  times.  These  values  are  loaded  on  File  26  by  the  Air  Ground 
Engagement  Model  load  program  (Chapter  10) . 

3.  SECOND  PRIORITY  EQUIPMENT  ITEMS.  The  gamer  is  permitted  to  specify  which 
equipment  items  in  a  unit  to  be  airlifted  are  of  secondary  criticality.  When 
an  airlift  is  executed,  all  primary  items  are  loaded  first.  These  are  items 
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that  must  be  taken  with  the  first  element.  The  remaining  items  are  those 
items  which  are  desired  to  be  airlifted  but  which,  due  to  time  or  capacity 
constraints,  may  be  left  at  the  pickup  zone  until  the  transport  aircraft 
return  for  subsequent  loads.  The  card  format  is  shown  at  Figure  IV-15-A-1. 

a.  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  1  has  been 
preprinted  into  card  column  1;  make  no  changes.  In  card  column  2,  only  one 
of  two  entries  is  permitted;  "R"  for  Red  forces  or  "B"  for  Blue  forces. 

b.  Equipment  Item  Code  (Columns  3-71).  In  these  columns,  enter  equipment 
item  codes  of  second  priority  items.  Up  to  23  second  priority  item  codes 

may  be  listed  on  this  card,  and  the  order  on  the  card  has  no  significance 
since  items  within  the  second  priority  are  not  assigned  a  further  priority. 
Additional  cards  may  be  used  if  necessary.  Equipment  item  codes  are  right 
justified  in  the  field. 

c.  Card  ID.  In  card  columns  73-76  enter  the  numbers  0701. 

4.  MIX  TABLE.  The  gamer  must  specify  the  mix  of  aircraft  which  is  to  perform 
an  airmobile  operation.  The  transport  and/or  escort  aircraft  typed  to  be  used 
are  specified  on  card  form  0702  (Figure  IV-15-A-2.',  Each  card  represents  a  dif¬ 
ferent  mix  which  may  be  requested  by  the  gamers  through  use  of  DSL. 

a.  Card  Type  and  Force  Designator  (Columns  1-2) .  The  number  1  has  been 
preprinted  in  column  1.  Make  no  changes.  In  column  2  only  one  of  two  entries 
is  permitted;  "R"  for  Red  forces  or  "B"  for  Blue  forces. 

b.  Mix  (Columns  3-4) .  Each  card  represents  a  different  mix  of  aircraft 
to  perform  an  airmobile  mission.  The  mix  specified  by  the  gamer  must  be 
unique  and  have  a  unique  mix  number  which  refers  to  the  numbers  entered  in 
these  columns.  Enter ’the  integer  1  in  these  columns  for  the  first  mix,  a  2 
for  the  second  mix,  and  so  forth.  A  maximum  of  10  mixes  is  permitted  for 
each  force. 

c.  Escort  Aircraft  (Columns  6-52) .  The  aircraft  which  will  escort  the 
transport  aircraft  during  an  airmobile  operation  are  described  in  these 
columns.  This  description  includes  the  escort  aircraft  identification,  air¬ 
craft  crew  requirements,  fuel  capacity,  number  of  fuel  inlets  on  the  aircraft, 
the  munition  load,  and  a  rearm  time.  Mixes  which  do  not  include  escorts  may 
be  defined,  in  which  case  columns  6-52  are  left  blank. 

(1)  Escort  Aircraft  Identification  (Columns  6-8).  Enter  the  equipment 
item  code  of  the  aircraft  type  which  will  perform  the  escort  mission. 

(2)  Escort  Aircraft  Crew  Requirements  (Columns  10-11) .  Enter  the 
number  of  personnel  required  to  fly  a  single  aircraft  of  this  type.  When 

an  airmobile  operation  is  requested,  a  check  is  made  of  all  available  airbases 
to  determine  if  at  least  one  airbase  has  sufficient  personnel  and  equipment 
to  initiate  the  airlift.  If  a  particular  airmobile  operation  requires  four 
escort  aircraft,  each  aircraft  requiring  two  crew  members,  then  at  least  one 
airbase  must  have  a  minimum  of  four  escort  aircraft  and  eight  personnel  or 
the  mission  will  be  automatically  terminated. 
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ESCORT  AIRCRAFT  I  |  TRANSPORT  AIRCRAFT 


(3)  Escort  Aircraft  Fuel  (Columns  13-16).  Enter  the  initial  load 
quantity  of  fuel  in  gallons  of  the  aircraft  type  specified  in  columns  6-8, 
This  number  should  be  right  justified.  For  example  if  the  escort  aircraft 
is  to  be  an  AH-1G,  Cobra,  with  a  full  fuel  load  then  the  number  251  may  be 
entered  in  columns  14-16.  The  internal  fuel  capacity  of  the  AH-1G  is  251 
gallons. 


(4)  Number  of  Fuel  Inlets  -  Escorts  (Columns  18-19).  When  an  air¬ 
craft  is  refueled,  the  model  considers  the  number  of  refuel  inlets  on  the 
aircraft.  If  sufficient  refuel  nozzles  are  available,  an  aircraft  with  two 
inlets  will  be  refueled  twice  as  fast  as  if  it  had  only  one.  The  number  of 
refuel  inlets  per  aircraft  is  specified  in  these  columns. 

(5)  Munitions  (Columns  21-49) .  The  amount  and  type  of  ammunition 
to  be  loaded  on  each  escort  aircraft  for  a  given  mix  is  specified  in  these 
columns.  Up  to  three  munition  types  may  be  specified. 

(a)  Ammunition  Identification  (Columns  21-23).  Enter  the 
equipment  item  code  of  one  of  the  ammunition  types  which  is  to  be  loaded  on 
this  aircraft. 

(b)  Ammunition  Amount  (Columns  25-29) .  Enter  the  number  of 
rounds  of  the  ammunition  type  specified  in  columns  21-23  which  is  to  be 
loaded  on  each  escort  aircraft  of  the  type  specified  in  columns  6-8. 

(c)  Additional  Ammunition  Types  (Columns  31-49).  If  additional 
ammunition  types  are  to  be  loaded  on  the  escort  aircraft,  they  should  be 
entered  by  item  code  and  quantity  in  these  columns. 

(6)  Rearm  Time  (Columns  51-52).  Enter  in  minutes  the  time  required 
to  load  the  specified  escort  type  aircraft  with  a  full  load  of  the  ammunition 
types  specified  in  columns  21-49. 

d.  Transport  Aircraft  (Columns  59-72),  The  aircraft  which  will  be  used 
to  transport  the  units  to  be  airlifted  during  an  airmobile  operation  (if  this 
mix  is  specified)  is  described  in  these  columns.  This  description  includes 
the  transport  aircraft  identification,  aircraft  crew  requirements,  fuel 
capacity,  and  number  of  fuel  inlets  on  the  aircraft. 

(1)  Transport  Aircraft  Identification  (Columns  59-61).  If  the 
aircraft  mix  is  specified,  enter  the  equipment  item  code  of  the  aircraft  type 
which  will  be  the  transporting  vehicle. 

(2)  Transport  Aircraft  Crew  Requirements  (Columns  63-64).  Enter 
the  minimum  number  of  personnel  required  to  fly  a  single  aircraft  of  this 
type.  As  was  the  case  with  escort  aircraft,  at  least  one  airbase  must  have 
sufficient  aircraft  and  personnel  to  fly  the  required  transport  aircraft  or 
the  airmobile  mission  will  be  aborted. 


IV-15-A-5 


(3)  Transport  Aircraft  Fuel  (Columns  66-69).  Enter  in  gallons  the 
desired  fuel  load  of  the  aircraft  type  specified  in  columns  59-61. 

(4)  Number  of  Fuel  Inlets  -  Transports  (Columns  71-72).  Enter  the 
number  of  fuel  inlets  in  each  transport  aircraft  in  these  columns  (see  sub- 
paragraph  c(4)  above]. 

e.  Card  ID.  In  card  columns  73-76,  the  numbers  0702  will  be  written. 

5.  FORWARD  AREA  REARM  AND  REFUEL  (FARR)  AREA  DEFINITIONS.  When  the  task 
organization  is  defined,  forward  area  refuel  and  rearm  (FARR)  areas  are  also 
specified.  These  FARR  areas  are  assigned  unique  unit  type  designators  (UTDs). 
Card  Form  0703  (Figure  IV-15-A-3)  is  used  to  relay  the  UTD  types  for  the  FARR 
areas  to  the  Airmobile  Model. 


a.  Card  Type  and  Force  Designator  (Columns  1-2) .  The  number  1  has  been 
preprinted  in  card  column  1.  Make  no  changes.  In  column  2  only  one  of  two 
entries  is  permitted,  "R"  for  Red  force  or  "B"  for  Blue  force. 

b.  Unit  Type  Designator  (UTD)  (Columns  4-7).  Enter  the  four-character 
UTD  of  the  first  FARR  area. 

c.  Number  of  Rearm  Points  (Columns  9-10) .  A  rearming  point  is  a  site 

of  sufficient  size  with  sufficient  equipment  to  rearm  one  aircraft  at  a  time. 

If  there  is  more  than  one  rearming  point  in  a  FARR  area,  this  number  repre¬ 
sents  the  number  of  aircraft  that  can  simultaneously  be  rearmed.  Enter  in 
these  columns  the  number  of  rearming  points  present  in  a  unit  of  the  type 
designated  in  columns  4-7. 

d.  Additional  Forward  Rearm  and  Refuel  Areas  (Columns  12-66).  If  the 
FARR  areas  are  represented  by  more  than  one  UTD,  enter  the  UTD  and  associated 
number  of  rearming  points  for  each  in  the  appropriate  columns. 

e.  Card  ID.  In  card  columns  73-76  the  number  0703  will  be  written. 

6.  REFUEL  DEVICE  DEFINITION.  Each  forward  rearm  and  refuel  area  is  equipped 
with  one  or  more  forward  area  refueLing  equipment  (FARE)  systems.  Each  system 
contains  bulk  fuel  storage  equipment  and  fuel  outlets  or  nozzles.  The  number 
of  aircraft  that  can  be  simultaneously  refueled  is  directly  related  to  the 
number  of  nozzles  per  refuel  device.  Card  0704,  Figure  IV-15-A-4,  is  used  for 
this  purpose. 

a.  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  1  has  been 
preprinted  in  card  column  1.  Make  no  changes.  In  column  2,  only  one  of  two 
entries  is  permitted;  ''R"  for  Red  force  or  "B"  for  Blue  force. 

b.  Refuel  Device  Identification  (Columns  4-6).  Enter  the  equipment  item 
code  of  the  first  refuel  device. 
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AND  THE  NUMBER  OF  REARM  POINTS  (NRAP)  ASSICNED  TO  EACH 


REFUEL  DEVICE  DEFINITION 


c.  Number  of  Nozzles  (Columns  9-10).  Enter  the  number  of  refuel  nozzles 
available  in  the  refuel  device  given  in  columns  4-6. 

d.  Additional  Refuel  Devices  (Columns  13-37).  Enter  in  these  columns 
the  item  code  and  number  of  nozzles  for  any  additional  refuel  devices.  A 
maximum  of  10  devices  may  be  specified. 

e.  Maneuver  Times  (Columns  64-72).  The  total  service  time  of  an  aircraft 

*  at  a  FARR  area  includes: 

•  .  time  to  maneuver  into  a  refuel  point  from  a  point  about  200  yards 

away 

.  time  to  refuel 

.  time  to  maneuver  out  of  the  refuel  point  to  a  point  where  it  may 
either  leave  the  FARR  area  or  enter  a  rearm  queue 

.  time  to  maneuver  into  the  rearming  point 

.  time  to  rearm 

.  time  to  maneuver  out  of  the  rearming  point  to  an  area  where  it 

can  either  wait  for  the  rest  of  the  flight  or  it  can  leave  the 
FARR  area. 

The  refueling  time  and  rearming  time  are  calculated  by  the  model.  The  other 
times  are  input  in  the  constant  data  base. 

(1)  Refueling  Maneuver  Time  (Columns  64-67) .  Enter  in  minutes  the 
refueling  maneuver  time.  This  includes  the  time  required  to  maneuver  into  a 
refuel  point  from  a  point  about  200  yards  away  plus  the  time  to  maneuver  out 
of  the  refuel  point  to  a  point  where  the  aircraft  may  either  leave  the  FARR 
area  or  enter  a  rearm  queue. 

(2)  Rearming  Maneuver  Time  (Columns  69-72).  Enter  in  minutes  the 
rearming  maneuver  time.  This  includes  the  time  required  for  the  aircraft 

to  maneuver  into  the  rearming  point  plus  the  time  required  for  it  to  maneuver 
out  of  the  rearming  point  to  an  area  where  it  can  either  wait  for  the  rest 
of  the  flight  or  it  can  leave  the  FARR  area. 

f.  Card  ID.  In  columns  73-76,  enter  the  number  0704. 

«  7.  SUPPRESSION  MISSION  DATA  (GTAA) .  The  gamer  must  specify  the  information 
necessary  to  establish  the  effects  of  suppression  against  air  defense  capable 

«  units  (ADCU)  by  escort  aircraft,  high  performance  aircraft  (TACAIR) ,  and  ground- 
based  artillery.  The  distances  from  an  airmobile  column  and  the  times  for 
responding  to  and  suppressing  air  defense  units  are  specified  on  card  form 
0740,  Figure  IV-15-A-5.  A  single  0740  card  is  required  for  each  force.  All 
card  entries  are  right  justified  unless  otherwise  stated. 
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a.  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  1  has  been 
preprinted  in  column  1.  Make  no  changes.  In  column  2  only  one  of  two  entries 
is  permitted;  "R"  for  Red  forces  or  "B"  for  Blue  forces. 

b.  Escort  Divert  Limit  (Columns  4-7).  The  distance,  in  meters,  from  an 
airmobile  column  that  escort  aircraft  are  permitted  to  divert  to  suppress  air 
defense  capable  units  is  entered  in  columns  4-7.  This  distance  to  be  entered 
is  the  sum  of  the  actual  separation  distance  of  the  escort  aircraft  from  the 
airmobile  column  and  the  stand-off  distance  of  the  escort  aircraft  from  the 
target.  For  example,  if  an  attack  helicopter  is  the  escort  aircraft  with  tne 
TOW  as  its  weapon  system,  then  a  stand-off  distance  of  3000  meters  (range  of 
the  TOW)  and  a  divert  distance  of  6000  meters  yields  a  divert  limit  of  9000 
meters,  which  would  be  entered  in  columns  4-7. 

c.  TACAIR/Ground-Based  Artillery  Fire  Response  Time  (Columns  9-12).  The 
time,  in  seconds,  for  either  TACAIR  or  ground-based  artillery  to  provide  fire 
for  suppression  of  air  defense  capable  units  is  entered  in  this  field.  TACAIR 
or  ground-based  artillery  fire  will  be  requested  when  escort  aircraft  cannot 
be  diverted  for  suppression  of  air  defense  capable  units.  TACAIR  as  used  by 
the  inflight  attrition  portion  of  the  DIVWAG  system  assumes  an  air  alert. 

d.  Duration  of  Escort  Suppression  Mission  (Columns  24-27).  The  time,  in 
seconds,  that  an  escort  aircraft  attacks  the  air  defense  capable  unit  (i.e.  , 
remains  "on  station")  on  a  suppression  mission  is  entered  in  this  field.  This 
datum  is  used  in  calculating  the  total  time  that  an  air  defense  capable  unit 
is  suppressed. 

e.  Escort  Suppression  Response  Time  (Columns  29-32).  The  average  time, 
in  seconds,  required  by  e  ;cort  aircraft  in  an  airmobile  flight  en  route  to  a 
landing  zone  to  break  formation  and  take  an  air  defense  capable  unit  under 
fire  is  entered  in  this  field. 

f.  Time  After  Passing  ADCU  Beyond  Which  Escorts  Will  Not  Divert  (Columns 
24-37).  The  time,  in  seconds,  after  passing  an  air  defense  capable  unit  that 
the  escort  aircraft  will  not  be  permitted  to  fly  to  the  rear  for  suppression 
missions  is  entered  in  this  field.  This  time  should  be  directly  related  to 
the  escort  divert  limit  distance  in  columns  4-7  but  should  not  exceed  the  time 
the  aircraft  requires  to  fly  back  to  a  stand-off  distance  to  engage  an  air 
defense  capable  unit. 

g.  Card  ID  (Columns  73-76).  The  number  0740  has  been  preprinted  in  this 
field.  Make  no  changes. 

8.  ACQUISITION  DATA.  Two  card  types  are  required  to  record  air  defense 
capable  unit  data.  The  type  data  required  for  these  cards  are  found  in  field 
test  data,  specifically  CDCEC  43.6  test.  There  is  currently  no  known  docu¬ 
mented  source  for  all  required  data;  therefore,  some  data  entries  may  have 
to  be  derived  through  sound  military  logic.  In  this  case  it  is  important 
that  data  on  opposing  forces  be  carefully  reviewed  by  the  gaming  staff  before 
the  data  are  entered  into  the  constant  data  base. 
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a.  Acquisition  Data  Card  ID  0741,  Card  Type  1.  The  card  type  1,  shown  in 
Figure  IV-15-A-6,  is  used  to  record  the  slant  ranges  from  air  defense  weapons 
to  aircraft  by  acquisition  types.  Three  different  acquisition  types  may  be 
specified;  i.e.,  acquisition  type  1  for  units  with  gun  type  weapons  and  short 
range  missiles  against  rotary  wing  aircraft;  acquisition  type  2  for  units  with 
gun  type  weapons  and  short  range  missiles  against  fixed  wing  aircraft;  and 
acquisition  type  3  for  units  with  medium  and  long  range  missiles  against  fixed 
wing  aircraft.  A  separate  card  is  required  for  each  acquisition  type. 

(1)  Card  Type  and  Force  Designator  (Columns  1-2) .  The  number  1  has 
been  preprinted  in  column  1.  Make  no  changes.  In  column  2  only  one  of  two 
entries  is  permitted;  "R"  for  Red  forces  or  "B"  for  Blue  forces. 

(2)  Acquisition  Type  (Column  4) .  Enter  the  acquisition  type  in  this 
field.  If  the  aircraft  to  be  detected  is  rotary  wing  and  the  seekers  are 
equipped  with  gun  type  weapons  or  short  range  missiles,  enter  1;  if  the  air¬ 
craft  type  to  be  detected  is  fixed  wing  and  the  seekers  are  equipped  with  gun 
type  weapors  or  short  range  missiles,  enter  2;  if  the  aircraft  type  to  be 
detected  is  fixed  wing  and  the  seekers  are  equipped  with  medium  and  long  range 
missiles,  enter  3. 

(3)  Number  of  Aircraft  in  Flight  (Columns  6-10).  In  these  columns 
enter  the  number  of  aircraft  in  a  flight  which  could  be  detected.  Enter  the 
minimum  number  of  aircraft  in  columns  6-7,  the  maximum  number  of  aircraft  in 
columns  12-13,  and  an  intermediate  value  for  the  number  of  aircraft  between 
the  minimum  and  maximum  in  columns  9-10.  Three  values  for  numbers  of  air¬ 
craft  must  be  entered. 

(4)  Ranges  from  Air  Defense  Weapons  to  Aircraft  (Columns  15-37).  In 
these  columns  enter  the  slant  ranges  (four  ranges  are  required),  in  meters,  at 
which  aircraft  may  be  acquired.  Enter  the  ranges  in  increasing  increments  with 
the  shortest  range  in  columns  15-19  and  the  longest  range  in  columns  33-37. 

(5)  Card  ID  (Columns  73-76).  The  number  0741  has  been  preprinted  in 
this  field.  Make  no  changes. 

b.  Acquisition  Data,  Card  ID  0741,  Card  Type  2.  The  card  type  2,  shown 
in  Figure  IV-15-A-7,  is  used  to  record  the  probability  of  detection  and  median 
time  to  detect  at  each  of  the  four  ranges  specified  in  card  type  1.  Ine  card 
type  2  is  required  for  each  number  of  aircraft  (card  type  1)  which  can  be 
acquired  by  each  acquisition  type. 

Cl)  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  2  has 
been  preprinted  into  card  column  1;  make  no  changes.  In  card  column  2,  only 
one  of  two  entries  is  permitted;  "R"  for  Red  forces  or  "B"  for  Blue  forces. 

(2)  Acquisition  Type  (Column  4).  Enter  the  acquisition  type  in  this 

field. 
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(3)  Number  of  Aircraft  in  Flight  (Columns  6-7).  Enter  the  number  of 
aircraft  in  the  flight  for  the  acquisition  type  specified  in  column  4.  One 
card  is  required  for  each  of  the  three  values  specified  for  the  number  of  air¬ 
craft;  therefore,  three  cards  type  2  are  required  for  each  acquisition  type. 

(4)  Probability  of  Detection  and  Median  Time  to  Detect  (Columns  9-39). 

(a)  Range  1.  Enter  the  probability  of  detection  in  columns  9-11 
and  the  median  time  to  detect,  in  seconds,  in  columns  13-15  for  the  first  slant 
range  specified  in  card  type  1. 

(b)  Range  2.  Enter  the  probability  of  detection  in  columns  17-19 
and  the  median  time  to  detect,  in  seconds,  in  columns  21-23  for  the  second 
slant  range  specified  in  card  type  1. 

(c)  Range  3.  Enter  the  probability  of  detection  in  columns  25-27 
and  the  median  time  to  detect,  in  seconds,  in  columns  29-31  for  the  third  slant 
range  specified  in  card  type  1. 

(d)  Range  4.  Enter  the  probability  of  detection  in  columns  33-36 
and  the  median  time  to  detect,  in  seconds,  in  columns  37-39  for  the  fourth  slant 
range  specified  in  card  type  1. 

(5)  Card  ID  (Columns  73-76).  The  number  0741  has  been  preprinted  in 
this  field.  Make  no  changes. 

9.  AIRCRAFT  DATA.  The  data  used  to  describe  the  presented  area  of  each 
aircraft  by  equipment  item  code  and  type  as  well  as  the  average  evasive  maneu¬ 
ver  turn  rate  are  specified  on  card  form  0745  (Figure  IV-15-A-8) .  The  air¬ 
craft  which  must  be  described  in  these  cards  are  those  to  be  emploved  in  air¬ 
mobile  operations  and  reconnaissance  flights.  Each  card  represents  a  single 
aircraft. 

a.  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  1  has  been 
preprinted  into  card  column  1;  make  no  changes.  In  card  column  2,  only  one 
of  two  entries  is  permitted;  "R"  for  Red  forces  or  "B”  for  Blue  forces. 

b.  Aircraft  Item  Code  (Columns  5-7).  In  these  columns,  enter  the 
equipment  item  code  for  the  aircraft  to  be  described. 

c.  Aircraft  Presented  Areas  (Columns  9-28).  The  presented  areas,  in 
square  meters,  for  bottom,  side,  and  front/rear  are  described  in  these  columns. 

(1)  Bottom  (Columns  9-14).  Enter  the  presented  area  of  the  bottom 
of  the  aircrafc.  A  decimal  point  must  be  entered  in  column  12. 

(2)  Side  (Columns  16-21).  Enter  the  presented  area  of  the  side  of 
the  aircraft.  A  decimal  point  must  be  entered  in  column  19. 

(3)  Front/Rear  (Columns  23-28).  Enter  the  presented  area  of  the 
front/rear  of  the  aircraft.  A  decimal  point  must  be  entered  in  column  26. 
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AIRCRAFT  PRESENTED  AREAS 
(METERS  SQUARED) 


d.  Aircraft  Average  Evasive  Maneuver  Turn  Rate  (Columns  30-33).  The 
evasive  maneuver  turn  rate,  in  gravities  (g) ,  which  this  aircraft  will  employ 
on  an  average  basis  during  the  types  of  employment  contemplated  is  entered  in 
this  field.  Note  that  a  decimal  point  must  be  entered  in  column  31.  This  turn 
rate  is  not  the  same  as  the  theoretical  turn  rate  capability  of  the  aircraft, 
since  in  practice,  such  as  in  an  airmobile  column,  the  freedom  to  employ  eva¬ 
sive  maneuver  may  be  severely  limited.  Also  the  desired  value  is  an  average 
for  the  entire  duration  of  flight  while  under  enemy  fire. 

e.  Aircraft  Type  (Column  38).  The  aircraft  type  is  entered  in  this 
column.  Enter  1  if  the  aircraft  is  a  rotary  wing  aircraft.  Enter  2  is  the 
aircraft  is  a  fixed  wing  aircraft. 

f.  Card  ID  (Columns  73-76).  The  number  0745  is  preprinted  on  this  field. 
Make  no  changes. 

10.  AIR  DEFENSE  WEAPON  DATA.  The  gamer  must  specify  the  characteristics  of 
all  air  defense  weapon  system  by  equipment  item  code  and  its  associated  char¬ 
acteristics  are  specified  on  card  form  0750.  Six  card  types;  i.e.  ,  card  types 
1  through  6,  are  necessary  to  enter  all  the  data.  Before  the  air  defense  wea¬ 
pon  data  cards  are  completed  for  a  given  war  game,  a  thorough  analysis  must  be 
made  of  the  purpose  and  objectives  of  the  game  to  determine  the  significance 
attached  to  air  defense  play.  An  objective  decision  can  then  be  made  concern¬ 
ing  the  various  available  air  defense  capable  weapons  that  are  to  be  played. 
This  submodel  is  time  consuming  when  being  executed  in  the  system;  accordingly, 
it  is  uneconomical  to  include  weapons  chat  make  no  significant  contribution  to 
the  game  or  game  results. 

a.  Card  Type  1  (Figure  IV-15-A-9).  The  card  type  1  contains  14  data 
fields. 


(1)  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  1  has 
been  preprinted  in  column  1.  Make  no  changes.  In  column  2  only  one  of  two 
entries  is  permitted;  "R"  for  Red  forces  or  "B"  for  Blue  forces. 

(2)  Weapon  Item  Code  (Columns  5-7).  Enter  the  equipment  item  code 
of  the  air  defense  weapon  in  this  field.  A  convention  should  be  established 
wherein  the  equipment  item  codes  are  listed  sequentially. 

(3)  Fire  Control  Type  Code  (Columns  9-11).  The  type  of  fire  control 
associated  with  each  air  defense  weapon  is  inserted  in  this  field.  Four  types 
of  fire  control  are  associated  with  gun  type  systems,  as  follows: 

.  Fire  Control  Type  1.  If  the  gun  system  is  small  caliber;  i.e.  , 
12.7mm  or  0.50  caliber,  and  visually  sighted,  enter  the  integer 
1. 


Fire  Control  Type  2.  If  the  gun  system  is  mid  caliber;  i.e., 
14.5mm  through  57mm,  and  optically  sighted,  enter  the  integer 
d. 


Fire  Control  Type  3.  If  the  gun  system,  irrespective  of  caliber, 
is  controlled  by  a  range  only  radar  system,  enter  the  integer  3. 
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Figure  IV-15-A-9.  Air  Defense  Weapon  Data  (Card  Type  1)  Card  Format 


.  ri.ro  Control  Type  4.  If  the  gun  system,  irrespective  of  caliber, 
is  controlled  by  a  full  resolution  radar  system,  enter  the 
integer  4. 

fife  control  type  categories  are  not  applied  to  missile  type  weapon  systems. 
duc.<  ..'.issile  type  is,  instead,  assigned  a  unique  number,  starting  with  the 
into,, or  11  for  each  force.  In  addition  to  identifying  the  weapon  equipment 
he:;  code  as  a  missile,  the  missile  type  code  assigned  here  is  used  to  simplify 

*  c.v..i  of  certain  missile  characteristics  data,  in  lieu  of  the  weapon  item  code; 
-..orotore,  the  missile  codes  must  be  assigned  in  continuous  progression  from 

■  .  *  -award,  in  the  order  that  missile  weapons  appear  on  this  data  card.  On  all 

a ua sequent  car-s,  missile  weapon  item  codes  should  be  listed  in  this  same  order. 

<k 

(4)  Maximum  Effective  Slant  Range  (Columns  13-18).  Enter  the  maximum 
effective  slant  range,  in  meters,  of  the  weapon  system  being  described. 

(5)  Assigned  Radius  of  Responsibility  for  Targets  (Columns  20-25) . 

Enter  tae  distance,  in  meters,  of  the  radius  of  target  responsibility  for 

the  weapon  being  described.  Some  judgment  is  required  in  making  the  entry  for 
this  field.  The  entry  is  one  of  the  characteristics  used  to  determine  if  a 
weapon  qualifies  for  firing  against  a  given  aircraft  flight  that  is  in  progress. 
Considering  the  air  defense  systems  organic  to  a  division,  a  reasonable  entry 
is  tiie  maximum  effective  slant  range  of  the  weapon;  however,  in  considering 
air  defense  systems  that  are  available  to  the  division  (i.e.,  the  long  range 
missile  systems)  some  judgment  is  in  order  when  making  this  entry.  A  case  in 
point  could  be  made  of  the  Nike  Hercules.  If  the  slant  range  were  entered  in 
tn.is  field  it  is  unlikely  that  any  enemy  aircraft  could  penetrate  the  division 
cone  without  the  system  being  called  upon  as  a  firing  candidate. 

(6)  Capability  -  Night  (Column  27).  If  the  weapon  system  being 
described  has  the  capability  to  engage  targets  at  night,  enter  a  value  of  1. 

If  t'ae  weapon  has  no  nighttime  capability,  enter  0. 

(7)  Capability  -  Poor  Weather  (Column  30).  If  the  weapon  system 

*  being  described  has  the  capability  to  engage  targets  in  poor  weather,  enter 
a  value  of  1.  If  the  weapon  has  no  poor  weather  capability,  enter  0. 

(8)  Target  Altitude  Capability  (Columns  32-42).  Enter  the  maximum 
altitude,  in  feet,  that  aircraft  can  be  engaged  by  this  weapon  system  in  col¬ 
umns  32-37.  Enter  the  minimum  altitude,  in  feet,  that  aircraft  can  be  engaged 

<  by  this  weapon  system  in  columns  39-42.  A  point  to  remember  is  that  nap  of 
the  earth  is  defined  within  the  DIVWAG  system  as  50  feet  altitude. 

♦ 

(9)  Target  Speed  Capability  (Columns  44-51).  Enter  the  maximum 

,  flight  speed,  in  knots,  of  an  aircraft  against  which  this  weapon  system  can 
engage  in  columns  44-47.  Enter  the  minimum  flight  speed,  in  knots,  against 

^  which  this  weapon  system  can  engage  in  columns  49-51. 

(10)  Projectile  Drag  Coefficient  (Columns  53-56).  The  drag  coefficient 
of  gun  type  projectiles  (in  meters  per  second)  is  entered  in  columns  53-56.  A 
decimal  point  must  be  inserted  in  column  53  for  each  gun  type  system.  No  entry 

t 
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is  required  in  this  field  for  missile  type  systems.  If  these  data  are  not 
available  for  gun  systems  of  both  forces  being  gamed,  either  the  data  for 
each  force  should  be  derived  judgmentally  or  Red  force  data  should  be  a  mir¬ 
ror  image  of  Blue  force  data. 

(11)  Average  Delay  From  Acquisition  to  Fire/Launch  (Columns  56-60). 
Enter  the  delay  time,  in  seconds,  between  target  acquisition  and  projectile 
launch  for  gun  and  missile  type  systems. 

(12)  Air  Defense  Munition  Item  Code  (Columns  62-64).  Enter  the 
equipment  item  code  of  the  air  defense  munition  delivered  by  this  weapon  sys¬ 
tem  in  columns  62-64.  In  instances  wherein  the  weapon  and  munition  may  be  the 
same;  e.g. ,  the  REDEYE,  the  munition  equipment  items  code  will  be  the  same  as 
the  weapon  equipment  item  code  specified  in  columns  5-7. 

(13)  Muzzle  Velocity  (Columns  66-69).  Enter  the  muzzle  velocity,  in 
meters  per  second,  for  all  gun  type  systems.  Make  no  entry  in  this  field  for 
missile  type  systems. 

(14)  Card  ID  (Columns  73-76).  The  number  0750  has  been  preprinted  in 
this  field.  Make  no  changes. 

b.  Card  Type  2  (Figure  IV-15-A-10) .  Data  on  selected  characteristics  of 
air  defense  missile  systems  only  are  entered  on  card  type  2. 

(1)  Card  Type  and  Force  Designator  (Columns  1-2). 

(2)  Weapon  Item  Code  (Columns  5-7).  Enter  the  equipment  item  code 
of  the  missile  type  weapon  system  in  this  field. 

(3)  Slant  Range  Points  (Columns  9-34).  Five  Slant  range  entries, 
in  meters,  must  be  specified  in  this  field.  The  first  slant  range  entry, 
columns  9-12),  must  be  the  minimum  slant  range  capability  followed  in  ascend¬ 
ing  order  to  the  maximum  slant  range  capability  entered  in  columns  30-34.  Do 
not  omit  a  slant  range  point,  but  make  an  entry  for  each  range  point. 

(4)  Time  of  Flight  (Columns  36-51).  Five  time  of  flight  entries,  in 
seconds,  must  be  specified  in  this  field.  The  time  of  flight  entries  must  be 
made  against  the  corresponding  entries  for  slant  range  points. 

(5)  Missile  Guidance  Error  (Columns  53-59).  Enter  the  missile 
guidance  error,  in  meters,  for  the  minimum  slant  range  in  columns  53-55. 

Enter  the  missile  guidance  error,  in  meters,  at  the  maximum  slant  range  in 
columns  57-59.  The  Period  Processor  of  the  DIVWAG  system  performs  a  straight 
line  interpolation  to  find  missile  guidance  errors  at  ranges  between  the  min¬ 
imum  and  maximum  slant  ranges. 

(6)  Maximum  Slew  Rates  (Columns  61-69).  Enter  the  maximum  elevation 
rate,  in  degrees  per  second,  in  columns  61-64.  Enter  the  maximum  azimuth  slew 
rate,  in  degrees  per  second,  in  columns  66-69. 

(7)  Card  ID  (Columns  73-76).  The  number  0750  is  preprinted  in  this 
field.  Make  no  changes. 
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c.  Card  Type  3  (Figure  IV-15-A-11).  Additional  entries  regarding  air 
defense  weapon  data  characteristics  are  entered  on  card  type  3  for  both  missile 
and  gun  type  systems. 

(1)  Card  Type  and  Force  Designator  (Columns  1-2) .  The  number  3  has 
been  preprinted  in  column  1.  Hake  no  changes.  In  column  2  only  one  of  two 
entries  is  permitted;  "R"  for  Red  forces  or  "B:  for  Blue  forces. 

(2)  Weapon  Item  Code  (Columns  5-7).  Enter  the  equipment  item  code  of 
the  weapon  system  in  this  field. 

(3)  Infrared  Missile  Lock-On  (Columns  9-45) .  This  field  provides 
for  seven  entries  on  boundary  ranges  for  infrared  (IR)  missile  lock-on,  as  a 
function  of  the  direction  in  which  the  aircraft  is  flying  respective  to  the 
missile  site.  To  facilitate  entries,  first  picture  an  aircraft  flying  directly 
away  from  the  infrared  missile  site.  In  columns  9-13  enter  the  maximum  dis¬ 
tance  from  weapon  site  to  target  at  which  this  infrared  missile  will  still  lock 
on  to  that  target.  The  "average"  aircraft  in  this  field  is  assumed  to  be  a 
composite  of  the  types  being  played.  Next,  at  30-degree  increments,  visualize 
rotation  of  the  aircraft  with  respect  to  flight  of  the  missile  from  the  missile 
site.  At  30°  enter  in  columns  15-19  the  lock-on  boundary  range.  At  60°  enter 
in  columns  21-25  the  lock-on  boundary  range,  and  so  on  through  90°,  120°,  150°, 
and,  finally,  when  the  missile  approaches  the  aircraft  from  head-on  with  respect 
to  the  missile  site. 

(4)  Rounds  Per  Burst  (Columns  47-49).  Enter  the  number  of  rounds 
fired  per  burst  for  automatic  type  gun  systems  in  this  field.  Make  no  entry 
in  this  field  for  any  other  type  system. 

(5)  Delay  Between  Bursts  of  Missiles  (Columns  56-58).  Enter  the  time, 
in  seconds,  for  delays  between  bursts  for  automatic  type  weapons  or  single  mis¬ 
siles  or  rounds  for  other  type  weapon  systems  in  this  field.  The  time  entered 
in  this  field  must  be  between  1  and  999  seconds. 

(6)  Magazine  or  Launcher  Capacity  (Columns  60-63) .  Enter  the  magazine 
(for  guns)  and  launcher  (for  missile)  capacity,  in  rounds/missiles,  in  the 
field. 

(7)  Reload  Delay  (Columns  65-68).  Enter  the  time,  in  seconds, 
required  to  reload  a  gun  magazine  or  belt  into  the  gun,  or  to  reload  missiles 
onto  the  launcher. 

(8)  System  Reliability  Factor  (Columns  70-72).  Enter  the  system 
reliability  factor,  in  percent,  in  this  field.  These  data  are  readily  avail¬ 
able  from  field  tests  and  in  technical  publications  for  Blue  systems.  If  Red 
data  are  not  available,  the  gaming  group  will  have  to  determine  whether  judg¬ 
mental  entries  are  required  or  a  mirror  image  of  a  similar  Blue  weapon  will 
suffice. 

(9)  Card  ID  (Columns  73-76).  The  number  0750  has  been  preprinted  on 
this  card.  Make  no  changes. 
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d.  Card  Type  4  (Figure  IV-15-A-12).  This  card  type  provides  data  entries 
that  present  the  degradation  to  air  defense  weapons  as  a  result  of  weather- 
visibility  (WV)  conditions  and  levels  of  electronic  countermeasures  (ECM)  that 
are  directed  at  the  air  defense  systems.  It  also  provides  an  entry  that 
describes  the  percent  damage  necessary  to  silence  each  system. 

(1)  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  4  has 
been  preprinted  into  card  column  1;  make  no  changes.  In  card  column  2,  only 
one  of  two  entries  is  permitted;  "R"  for  Red  forces  or  "B"  for  Blue  forces. 


(2)  Weapon  Item  Code  (Columns  5-7). 
the  weapon  system  in  this  field. 


Enter  the  equipment  item  code  of 


(3)  Capability  Degradation  as  a  Function  of  Weather-Visibility 
(Columns  9-27).  This  field  is  subdivided  into  five  subfields  that  are  used 
to  enter,  in  percent,  the  degrading  effect  on  the  air  defense  weapon  system  as 
a  result  of  weather-visibility  (WV)  conditions.  The  DIVWAG  system  allows  nine 
visibility  indexes  (VI)  as  described  in  Chapter  4  to  this  section.  For  pur¬ 
poses  of  the  Airmobile  Model,  the  visibility  indexes  are  equated  to  fire  wea¬ 
ther-visibility  conditions  as  follows: 


Weather-Visibility 

Condition 


Visibility 

Index 


Very  poor 
Poor 

Intermediate 

Fair 

Good 


(a)  Very  Poor  (Columns  9-11).  Enter  the  degradation,  in  percent, 
to  this  weapon  system  when  visibility  index  equals  1  or  2. 

(b)  Poor  (Columns  13-15).  Enter  the  degradation,  in  percent,  to 
the  weapon  system  when  the  visibility  index  equals  3  or  4. 

(c)  Intermediate  (Columns  17-19).  Enter  the  degradation,  in 
percent,  to  the  weapon  system  when  the  visibility  index  equals  5  or  6. 

(d)  Fair  (Columns  21-23).  Enter  the  degradation,  in  percent,  to 
the  weapon  system  when  the  visibility  index  equals  7  or  8. 

(e)  Good  (Columns  25-27).  Enter  the  degradation,  in  percent,  to 
the  weapon  system  when  the  visibility  index  equals  9. 

(4)  Degradation  Versus  Level  of  Electronic  Countermeasures  (Columns 
29-39).  This  field  is  subdivided  into  three  subfields  which  are  used  to  enter, 
in  percent,  the  degrading  effect  on  the  weapon  system  as  a  result  of  electronic 
countermeasures  (ECM)  directed  against  that  weapon  system.  Three  levels  of 
ECM  activity  are  considered  and  are  defined  as  follows:  heavy  ECM  is  assumed 
to  be  continuous,  concentrated  ECM  activity  against  the  air  defense  system  for 
the  duration  of  a  possible  ground-to-air  engagement;  moderate  ECM  is  assumed 
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to  be  concentrated  ECM  activity,  periodically  masked  or  otherwise  interrupted, 
for  the  duration  of  a  possible  ground-to-air  engagement;  and  light  ECM  is 
assumed  to  be  routine,  intermittent  ECM  activity  on  an  area  basis  as  opposed 
to  point  concentration. 

(a)  Heavy  ECM  (Columns  29-31).  Enter  the  degradation,  in  percent, 
to  this  weapon  system  when  there  is  continuous,  concentrated  ECM  activity 
against  the  system  for  the  duration  of  a  possible  ground-to-air  engagement. 

(b)  Moderate  ECM  (Columns  33-35).  Enter  the  degradation,  in 
percent,  to  this  weapon  system  when  there  is  concentrated  ECM  activity  period¬ 
ically  masked  or  otherwise  interrupted  for  the  duration  of  a  possible  ground- 
to-air  engagement. 

(c)  Light  ECM  (Columns  37-39).  Enter  the  degradation,  in  percent, 
to  this  weapon  system  when  there  is  routine,  intermittent  ECM  activity  on  an 
area  basis  as  opposed  to  point  concentration. 

(5)  Percent  Damage  Sufficient  to  Silence  Weapon  (Columns  41-43). 

Enter  the  level  of  damage,  in  percent,  required  to  silence  an  air  defense 
seapon  system. 

(6)  Card  ID  (Columns  73-76).  The  number  0750  has  been  preprinted  in 
this  field.  Make  no  changes. 

e.  Card  Type  5  (Figure  IV-15-A-13).  This  card  type  provides  kill 
probabilities  as  a  function  of  miss  distances  for  missiles  against  rotary 
wing  aircraft.  (See  Figure  IV-15-A-13.) 

(1)  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  5  has 
been  preprinted  in  column  1.  Make  no  changes.  In  column  2  only  one  of  two 
entries  is  permitted;  "R"  for  Red  forces  or  "B"  for  Blue  forces. 

(2)  Weapon  Item  Code  (Columns  5-7).  Enter  the  equipment  item  code 
of  the  missile  weapon  system  in  this  field. 

(3)  Fire  Control  Type  Code  (Columns  9-11).  The  fire  control  type 
code  was  discussed  in  subparagraph  a(3)  above.  As  discussed  therein,  fire 
control  type  codes  beginning  with  the  integer  11  were  assigned  for  each  missile 
type  system.  The  data  entered  in  card  type  1  for  a  specific  weapon  item  code 
must  be  entered  correspondingly  on  these  cards. 

(4)  Kill  Category  (Column  14).  Four  kill  categories  are  considered 
in  the  DIVWAG  system:  A-kill  (catastrophic  kill),  B-kill  (forced  landing), 
C-kill  (mission  abort),  and  D-kill  (hit,  but  minor  damage).  When  an  aircraft 
suffers  an  A-kill,  it  crashes  because  of  the  damage  inflicted  by  the  defending 
air  defense  weapons  and  is  not  recoverable  for  future  use.  Type  B-kill  forces 
the  aircraft  to  land  (powered  or  unpowered)  because  of  damage,  or  forces  it  to 
make  a  precautionary  landing  because  of  an  automatic  warning  signal  indicating 
trouble.  If  the  downed  aircraft  has  penetrated  enemy  airspace,  it  is  not  recov¬ 
erable  and  is  considered  destroyed.  If  no  penetration  of  hostile  territory 
occurred,  the  downed  aircraft  is  recovered  after  an  appropriate  delay  time. 
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It  can  Chen  be  used  in  future  engagements.  When  a  type  C-kill  occurs,  the 
aircraft  is  forced  to  discontinue  its  mission  because  of  damage  to  the  air¬ 
craft  or  because  of  a  pilot  or  copilot  casualty.  In  this  case,  the  aircraft 
immediately  breaks  off  its  engagement  with  the  target  and  returns  to  its  base. 
Type  C-kills  are  susceptible  to  additional  attrition  from  air  defense  weapons 
on  the  return  trip.  Aircraft  suffering  type  D-kills  are  considered  able  to 
complete  their  mission.  A  repair  time  is  imposed  on  them  when  they  return  to 
their  airbase.  Enter  the  kill  type  category  (i.e.;  A,  B,  C,  or  D)  in  this 
field;  thus,  four  cards  for  each  weapon  item  code/fire  control  types  are 
required  to  enter  data  for  all  four  types  of  kills. 

(5)  Probability  of  Kill  (Columns  17-48).  The  probability  of  kill,  in 
percent,  is  entered  in  the  11  subfields  shown  in  Figure  IV-15-A-13.  The  11 
subfields  represent  equally  spaced  range  points.  The  distance,  in  feet, 
between  range  points  is  specified  in  columns  50-52.  For  example,  given  a 
distance  between  range  points  of  10  feet,  the  10  subfields  would  represent 
miss  distances  of  0,  10,  20,  30,  40,  50,  60,  70,  80,  90,  and  100  feet  respec¬ 
tively.  A  range  point  of  0  corresponds  to  a  direct  hit.  The  probabilities  of 
kill  for  a  missile  detonating  at  the  miss  distances  calculated  are  entered  in 
the  respective  columns.  Annex  F  to  Airmobility  in  the  Mid/High-Intensity 
Environment  (Reference  6)  provides  some  of  the  data  required  by  this  card  type. 

(6)  Distance  Between  Range  Points  (Columns  50-52).  Enter  the  distance, 
in  feet,  between  each  of  the  range  points  defined  in  the  previous  subparagraph. 

(7)  Maximum  Lethal  Distance  (Columns  54-57).  Enter  the  maximum  lethal 
distance,  in  feet,  of  the  respective  missile  identified  in  columns  5-7  for  each 
kill  type. 

(8)  Card  ID  (Columns  73-76).  The  number  0750  is  preprinted  in  this 
field.  Make  no  changes. 

f.  Card  Type  6  (Figure  IV-15-A-14).  This  card  type  provides  kill 
probabilities  as  a  function  of  miss  distances  for  missiles  against  fixed  wing 
aircraft. 

(1)  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  6  has 
been  preprinted  in  column  1.  Make  no  changes.  In  column  2  only  one  of  two 
entries  is  permitted;  "R"  for  Red  forces  or  "B"  Blue  forces. 

(2)  Weapon  Item  Code  (Columns  5-7).  Enter  the  equipment  item  code 
of  the  missile  weapon  system  in  this  field. 

(3)  Fire  Control  Type  Code  (Columns  9-11).  The  fire  control  type 
code  was  discussed  in  subparagraph  a (3)  above.  As  discussed  therein,  fire 
control  type  codes  beginning  with  the  integer  11  were  assigned  for  each  mis¬ 
sile  type  system.  The  data  entered  in  card  type  1  for  a  specific  weapon  item 
code  must  be  entered  correspondingly  on  these  cards. 

(4)  Kill  Category  (Column  14).  Enter  the  kill  type  category  (i.e.; 

A,  B,  C,  or  D)  in  this  field;  thus,  four  cards  for  each  weapon  item  code/fire 
control  types  are  required  to  enter  data  for  all  four  types  of  kills. 
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(5)  Probability  of  Kill  (Columns  17-18).  The  probability  of  kill, 
in  percent,  is  entered  in  the  11  subfields  shown  in  Figure  IV-15-A-ll.  The 
11  range  points  is  specified  in  columns  50-52.  For  example,  given  a  distance 
between  range  points  of  10  feet,  the  ten  subfields  would  represent  miss 
distances  of  0,  10,  20,  30,  10,  50,  60,  TO,  80,  90,  and  100  feet  respectively. 
A  range  point  of  0  corresponds  to  a  direct  hit.  The  probabilities  of  kill 
for  a  missile  detonating  at  the  miss  distances  calculated  would  be  entered 

in  the  respective  columns.  Annex  F  to  Airmobility  in  the  Mid/Kigh-Intensity 
Environment  (Reference  6)  provides  some  of  the  data  required  by  this  card 
type. 

(6)  Distance  3etveen  Range  Points  (Columns  50-52).  Enter  the 
distances,  in  feet,  between  each  of  the  range  points  defined  in  the  previous 
subparagraph. 

(7)  Maximum  Lethal  Distance  (Columns  51-57).  Enter  the  maximum 
lethal  distance,  in  feet,  of  the  respective  missile  identified  in  columns 
5-7  for  each  kill  type. 

(8)  Card  ID  (Columns  73-76).  The  number  0750  is  preprinted  in  this 
field.  Make  no  changes. 

11.  AIR  SCATTERABLE  MINE  DELIVERY  DATA.  There  may  be  loaded  up  to  27  air¬ 
craft  resources  mix  tables,  nine  each  for  the  three  respective  aircraft 
types;  high  performance,  helicopter,  and  "other"  aircraft.  Mix  tables  will  be 
loaded  to  correlate  with  a  A  character  alphanumeric  mix  designator  or 
code  specified  in  the  DSL  order.  The  first  character  will  designate  the 
general  aircraft  type ;  A  =  high  performance , 

C  =  other  aircraft  types, 

H  =  helicopter. 

The  1th  character  will  be  an  integer  between  1  and  9  designating  the  mix 
table  within  the  general  aircraft  type.  The  3rd  character,  an  integer 
between  1  and  9,  points  to  a  desired  mission  flight  altitude. 

a.  Card  Type  1  (Figure  IV-15-A-15).  This  card  type  provides  aircraft 
mission  resource  data  as  a  function  of  mix  code.  One  card  must  be  used 
for  each  mix. 

(1)  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  1 
has  been  preprinted  in  column  1.  Make  no  changes.  In  column  2  enter  an 
R  or  3  representing  Red  or  Blue  force  respectively. 

(2)  General  Aircraft  Type  Code  (Column  3).  The  letter  A,  C,  or  H 
must  be  input  to  designate  the  aircraft  type;  high  performance,  other,  and 
helicopter  respectively. 

(3)  Mix  Code  (Column  1) .  An  integer  between  1  and  9  must  be  used 
to  designate  a  specific  resource  mix  within  a  general  aircraft  type. 
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(4)  Aircraft  Item  Code  (Columns  6-8).  Enter  the  equipment  item 
code  of  the  desired  aircraft  for  this  mission  mix. 

(5)  Crew  (Columns  10-11).  Enter  the  amount  of  aircraft  crew 
required  for  this  mission. 

(6)  Aircraft  Fuel  (Columns  13-l6).  Enter  the  amount  of  fuel 
(gal)  per  aircraft  required  for  mission. 

(7)  Item  Code  of  Mine  Type  (Columns  19-21,  29-31,  39-41 ).  Enter 
the  equipment  item  code  of  up  to  3  mine  types  to  be  delivered  in  this 
mission. 

(8)  Scatterable  Mine  Quantity  (Columns  23-26,  33-38,  43-46).  Enter 
the  quantity  of  each  mine  type  loaded  for  this  mission  mix. 

(9)  Dispensing  Rate  (Columns  50-53).  Enter  the  average  aircraft 
mine  dispensing  rate  (mines /minute/aircraft}. 

(10)  Strip  Width  (Columns  55-58).  Enter  the  average  width  (meters) 
of  a  strip  of  mines,  on  the  ground,  that  were  dispensed  from  a  single 
aircraft. 

(11)  Card  ID  (Columns  73-76),  The  number  0760  is  preprinted  in 
this  field.  Make  no  changes. 

All  card  entries,  except  (1),  are  integers  and  must  be  right  Justified 
in  data  field. 

b.  Card  Type  2  (Figure  IV-15-A-16  )•  This  card  type  provides  for 
up  to  9  mission  flight  altitudes.  Each  altitude  is  an  integer  and  must 
be  right  Justified  in  its  data  field. 

(1)  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  1 
has  been  preprinted  in  column  1.  Make  no  changes.  In  column  2  enter 

an  R  or  B  representing  the  Red  or  Blue  force  respectively. 

(2)  Altitude  Data  (Columns  4-8,  11-15,  18-22,  25-29,  32-36,  39-43, 
46-50,  53-57,  60-64).  Enter  up  9  mission  flight  altitudes  (feet). 

(3)  Card  ID  (Columns  73-76).  The  number  0761  is  preprinted  in 
this  field.  Make  no  changes. 

12.  AIRMOBILE  CONSTANT  DATA  DECK  STRUCTURE.  The  deck  structure  required 
by  the  Airmobile  Model  constant  data  load  program  and  the  data  listing 
generated  by  it  are  described  in  this  paragraph. 

a.  Airmobile  Constant  Data  Input  Cards.  The  card  types  required  by 
the  Airmobile  Model  are  listed  in  Figure  IV-15-A-15. 
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Card 

Type 

Card  Title 

Card 

ID 

Load 

Program 

1 

Second  Priority  Equipment  Items 

0701 

FIL7LD 

1 

: 

i  Airmobile  Mix  Tables 

0702 

FIL7LD 

1 

Forward  Rearm  and  Refuel  Area  Definitions 

0703 

FIL7LD 

1 

Refuel  Device  Definitions 

0704 

FIL7LD  | 

1 

Suppression  Mission  Data  (GTAA) 

0740 

FIL7LD  ' 

|  1 

1 

Acquisition  Data  (Card  Type  1) 

0741 

FIL7LD 

;  2 

Acquisition  Data  (Card  Type  2) 

0741 

FIL7LD 

j  1 

Aircraft  Data 

0745 

FIL7LD 

* 

j  1 

Air  Defense  Weapon  Data  (Card  Type  1) 

0750 

FIL7LD 

1  2 

Air  Defense  Weapon  Data  (Card  Type  2) 

0750 

FIL7LD 

!  3 

Air  Defense  Weapon  Data  (Card  Type  3) 

0750 

FIL7LD 

4 

t 

Air  Defense  Weapon  Data  (Card  Type  4) 

0750 

FIL7LD 

5 

Air  Defense  Weapon  Data  Rotary  Wing 
(Card  Type  5) 

0750 

) 

FIL7LD 

6 

Air  Defense  Weapon  Data  Fixed  Wing 
(Card  Type  6) 

0750 

FIL7LD 

1 

Air  Delivery  of  Scatterable  Mine  Mission 
Resources  Data 

0760 

FIL7LD  j 

i 

Aircraft  Flight  Altitudes  for  Dispensing 

Mines 

0761 

FIL7LD  | 
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b.  Creating  Constant  Data  Files  for  Airmobile  Model.  The  Airmobile 
Model  constant  data  input  file  is  created  by  reading  in  the  data  deck 
structured  as  illustrated  in  Figure  IV-15-A-16.  The  subdecks  that  form 
the  Airmobile  Model  data  deck,  with  Blue  force  data  preceding  Red  force 
data  are  shown.  At  the  left  side  of  the  figure  are  lb  groupings  of 

card  formats  that  are  used  to  assemble  the  subdecks  for  both  31ue  and  Red 
forces.  After  the  groupings  of  cards  are  aligned  as  shown  in  Figure  IV-15- 
A-16,  all  the  Blue  force  cards  are  then  assembled  for  the  first  subdeck. 

The  Red  force  data  are  then  organized  in  the  lU  groupings  as  shown  at  the 
left  of  the  figure  and  assembled  into  their  subdeck.  The  two  subdecks 
and  a  card  with  the  characters  END  DATA  punched  in  columns  72-80  are 
assembled  into  a  deck  as  shown  at  right  of  Figure  IV-15-A-16.  The  data 
deck  is  then  ready  for  insertion  of  the  system  control  cards  and  submission 
to  the  computer  system  for  creation  of  the  Airmobile  Model  constant  data 
input  files. 

c.  Updating  Airmobile  Model  Constant  Data  Files.  Changes  to  the  data 
read  into  the  constant  data  files  for  the  Airmobile  Model  can  be  readily 
accomplished  through  the  use  of  the  retained  Airmobile  Model  data  deck.  The 
updating  may  consist  of  correction  of  an  error  in  one  data  element,  the 
deletion  of  information,  or  the  addition  of  new  data. 

(1)  Correcting  an  Error.  The  card  with  the  error  or  data  to  be 
changed  is  located  and  a  new  card  is  produced  with  the  correct  or  changed 
data  punched  in.  The  old  card  is  removed  from  the  deck,  and  the  new  card 
is  inserted  in  its  location.  The  entire  data  deck  for  both  Red  ana  Blue 
forces  is  submitted  for  another  run  on  the  computer  system.  The  recreation 
of  the  constant  data  files  through  reading  in  the  data  deck  with  the 
changed  data  on  cards  constitutes  the  correction  of  an  error  or  the  chang¬ 
ing  of  a  data  element. 

(2)  Deletion  of  Information,  The  deletion  process  consists  of 
eliminating  the  entire  file  or  deleting  one  data  element  or  a  record.  The 
process  for  deleting  the  entire  Airmobile  Model  constant  data  file  uses  the 
control  card  to  erase  all  the  disk  storage  for  the  Airmobile  Model  constant 
data.  To  delete  a  data  element,  select  the  card  or  cards  having  unwanted 
data.  These  cards  are  removed  from  the  data  deck,  and  the  purged  deck  is 
submitted  for  reread  to  the  computer  system.  The  omission  of  cards  causes 
that  data  to  be  eliminated  from  the  data  base  in  the  process  of  recreating 
the  constant  data  files  for  the  Airmobile  Model. 

(3)  Addition  of  Data.  Data  may  be  added  at  any  time  prior  to  the 
start  of  the  game.  Prepare  the  cards  that  are  to  have  the  data  and  integrate 
them  into  the  data  deck  by  placing  each  of  the  card  formats  in  the  appropri¬ 
ate  subdeck  as  illustrated  in  Figure  IV-15-A-16.  When  these  cards  have 

been  accurately  integrated  into  the  data  deck  the  completed  and  expanded 
data  deck  is  submitted  to  the  computer  system  for  reread.  Each  time  data 
are  entered  in  the  Airmobile  Model  constant  data  input  file  printouts  are 
generated  showing  the  new  file  information. 


IV-15-A-33 


APPENDIX  B 


AIRMOBILE  MODEL  PROGRAM  DESCRIPTIONS 


1.  INTRODUCTION.  Routines  for  the  Airmobile  Model  are  contained  in  the 
DIVWAG  Period  Processor  overlay  17  wherein  the  main  area  contains  the 
overlay  executive  routine,  and  five  segments  treat  sequential  portions  of 
a  simulated  airmobile  operation.  The  macro  flow  of  the  Airmobile  Model 
appears  in  Figures  IV-15-1  through  IV-15-4  and  IV-15-8  through  IV-15-10. 

2.  ROUTINE  AMBLEX: 

a.  Purpose.  Program  AMBLEX  is  the  executive  driver  of  the  airmobile 
overlay.  It  calls  the  proper  segment  to  process  an  airmobile  event. 

b.  Input  Variables.  Standard  common  block  variables:  IDUM. 

c.  Output  Variables.  None. 

d.  Logical  Flow  (Figure  IV-15-B-1)  : 

(1)  Block  LI.  The  contents  of  IFNT(56,1)  are  set  to  zero. 

(2)  Blocks  2  and  3.  The  value  of  IDUM(94)  is  divided  by  10.  If 
this  value  is  equal  to  five,  routine  ATTDVR  is  called  to  begin  processing 
an  inflight  attrition  event. 

(3)  Block  L10.  The  value  of  IDUM(94)  is  divided  by  10  to  determine 
the  segment  number  to  be  called,  which,  in  turn,  processes  the  event. 

(4)  Block  4.  If  the  segment  has  set  the  cycle  flag  [IFNT(56,1) ] , 
another  airmobile  event  is  to  be  processed  immediately,  and  control  cycles 
back  to  block  LI. 

3.  ROUTINE  ACCPT : 

a.  Purpose.  ACCPT  is  the  executive  driver  routine  of  the  resource 
allocation  segment  of  the  Airmobile  Model.  It  calls  the  proper  routine 
to  process  each  event  following  a  DSL  accept  transport  order. 


b. 

Input  Variables: 

Name 

Source 

Contents 

IOPER 

TWO 

Operation  code. 

c. 

Output  Variables.  None. 

d.  Logical  Flow  (Figure  IV-15-B-2): 

(1)  Block  1.  Reduce  operation  code  by  10  to  filter  airmobile 
segment  code. 
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Figure  IV-15-B-1.  Routine  AMBLEX 
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(2)  Block  2.  Test  whether  code  is  w-'thin  correct  range. 

(3)  Block  3.  Print  error  message  if  code  is  incorrect. 

(4)  Block  4.  Control  branches  to  call  appropriate  routine. 

(5)  Blocks  L100,  L200,  and  L300.  Call  appropriate  routine  for 
the  accept  transport  segment  of  the  Airmobile  Model. 

4.  ROUTINE  ACCPT1 : 

a.  Purpose.  ACCPT1  is  called  by  program  ACCPT  at  the  beginning  of 
each  DSL  accept  transport  order.  Its  purpose  is  to  locate  and  select  the 
optimum  airbase(s)  for  supplying  the  airmobile  lift  with  the  necessary 
escort  and  transport  aircraft  and  related  resources.  A  mission  unit  is 
created  to  fly  the  aircraft  from  the  airbase (s)  to  the  pickup  point.  The 
aircraft  are  vulnerable  to  enemy  air  defense  fire  if  the  flight  to  the 
pickup  point  requires  penetration  of  enemy  air  defense  space.  If  two 
airbases  are  chosen,  one  to  supply  escort  aircraft  and  the  other  to  supply 
transport  aircraft,  an  escort  mission  unit  is  created  to  fly  to  the 
transport  airbase,  acquire  the  transport  resources  and  proceed  to  the 
pickup  point. 

b.  Input  Variables: 

(1)  Standard  Common  Block. 

(2)  Other  Variables: 


Name 

Source 

Contents 

IOPER 

TWO 

Operation  code. 

IUIDTP 

TWO 

Unit  to  be  transported. 

MIX 

TWO 

Resource  mix  code. 

ITPNUM 

TWO 

If  positive,  number  of  transport  aircraft 
if  negative,  number  of  trips  required. 

IPICKT 

TWO 

Time  to  be  at  pickup  point. 

CONSMP(IO) 

DF14 

Aircraft  fuel  consumption  rates. 

FLSPD(36) 

DF26 

Aircraft  flight  speeds. 

MIXTAB(12) 

F07 

Mission  resources. 

IESCAC 

MIXTAB ( 1) .  Item  code  for  escort  aircraft 

ESCPER 

MIXTAB(2) .  Number  of  personnel  per 
escort  aircraft. 
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Name 


Source 


Contents 


ESCL3A 

MIXTAB(3).  Gallons  of  fuel  per  escort 
aircraft. 

MUNITN (6) 

MIXTAB(i).  Item  code  and  amount  of  escort 
munitions  (up  to  three  different  types) . 

ITPAC 

MIXTAB(IO).  Item  code  for  transport  aircraft. 

TRNPER 

MIXTAB(ll).  Number  of  personnel  per  transport 
aircraft. 

TRNC3A 

MIXTAB (12).  Gallons  of  fuel  per  transport 
aircraft . 

ACAVL 

DF26 

Aircraft  item  codes. 

c. 

Output  Variables: 

(1) 

Standard  Common 

Block. 

(2) 

Other  Variables 

Name 

Destination 

Contents 

IDMSTR 

TWO 

Mission  unit  containing  both  escort  and  transport 
aircraft. 

IDESC 

TWO 

Escort  mission  unic  only. 

IDTRAN 

TWO 

Transport  mission  unit  only. 

FUEL 

TWO 

Fuel  consumed  from  airbase  to  pickup  point. 

TRANAB 

TWO 

Transport  airbase  identification. 

ESCAB 

TWO 

Escort  airbase  identification. 

d.  Logical  Flow  (Figure  IV-15-B-3) : 

(1)  Block  1.  Get  the  mission  resources  data  from  the  mix  table  on 
data  file  7.  See  MIXTAB  definitions  in  paragraph  b  above. 

(2)  Block  2.  Get  the  unit  status  record  of  the  unit  ordered  to 
accept  transport. 

(3)  Block  3.  Transfer  pertinent  resource  data  from  the  mix  table 
to  an  array  that  will  be  transferred  to  the  unit  status  records  of  the  unit 
accepting  transport  and  of  any  mission  units  that  may  be  created. 
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Figure  IV-15-B-3.  Routine  ACCPT1  (Continued) 
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Figure  IV-15-B-3.  Routine  ACCPT1  (Continued) 
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Figure  IV-15-B-3,  Routine  ACCPT1  (Continued) 
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Figure  IV-15-B-3.  Routine  ACCPT1  (Concluded) 


(4)  Block  4.  If  the  number  of  transport  aircraft  is  given,  control 
goes  to  block  L130.  If  the  number  of  trips  is  specified,  control  continues 
to  block  5. 


(5)  Block  5.  Determine  the  weight  and  volume  of  the  equipment  to 
be  moved,  excluding  any  aircraft  and  class  IIIA  fuel  that  the  unit  to  be 
transported  may  contain. 

(6)  Block  6.  Determine  the  weight  and  volume  capacity  of  the 
transport  aircraft  type  selected. 

(7)  Block  7.  Compute  the  number  of  transport  aircraft  loads  required 
to  move  the  equipment. 

(8)  Block  8.  Divide  the  number  of  trips  into  the  number  of  aircraft 
loads  to  determine  the  number  of  aircraft  required. 

(9)  Block  L130.  Routine  WETTHR  i?  called  to  determine  the  weather/ 
visibility  index  (0  to  3)  that  governs  the  aircraft  flight  speed. 

(10)  Block  L140.  Determine  friendly  airbases  and  store  in  a  list. 
Rank  the  list  by  proximity  to  the  pickup  point  within  each  of  the  three 
categories : 

.  Airbases  in  direct  support  to  the  unit  requesting  the 
transport 

.  Airbases  in  general  support  status 

.  Airbases  in  direct  support  to  other  units. 

(11)  Block  9.  Determine  the  flight  speed  of  the  escort  and 
transport  aircraft.  The  flight  speed  table  on  data  file  26  is  used. 

(12)  Block  10.  Calculate  the  aircraft  fuel  consumption  rates  for 
the  escorts  and  transports.  The  consumption  rates  are  taken  from  data  file 
14. 


(13)  Blocks  11  through  22.  These  blocks  show  a  search  technique 
to  locate  airbase(s)  which  can  satisfy  the  resource  requirements  for  this 
airmobile  mission.  First,  a  pass  is  made  through  the  list  of  eligible 
airbases  to  select  a  single  airbase  that  satisfies  all  resource  requirements. 
If  one  does  not  exist,  a  second  pass  is  made  to  select  two  airbases.  One 
will  supply  the  escort  aircraft  and  associated  resources;  the  other,  the 
transport  aircraft  and  resources.  If  two  airbases  cannot  be  found  the 
airmobile  mission. is  aborted. 

(14)  Blocks  23  and  24.  If  all  resources  have  not  been  located  by 
the  previous  selection  process,  an  error  message  is  printed  and  routine  XXIT 
is  called. 
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(15)  Block  L270.  Having  selected  an  airbase  to  supply  at  least  a 
portion  of  the  mission  resources,  a  mission  unit  is  created. 

(16)  Block  25.  Transfer  resources  from  the  airbase  to  the  air 
mission  unit (s) . 

(17)  Block  26.  The  activity  counters  on  the  airbase  unit  status 
record  are  incremented  to  record  the  number  of  aircraft  supplied  and  the 
number  of  operations  supported. 

(18)  Block  27.  If  this  is  the  first  pass,  all  requirements  are 
satisfied.  If  this  is  the  second  pass  and  both  mission  units  have  been 
created,  all  requirements  are  satisfied.  In  either  case,  control  goes  to 
block  28;  otherwise,  control  goes  to  block  14. 

(19)  Block  28.  Check  whether  aircraft  and  resources  were  found  on 
one  airbase  or  two.  If  from  one  airbase,  go  to  block  L432.  If  from  two 
airbases,  flow  continues  to  block  29. 

(20)  Block  29.  Calculate  the  distance  between  the  airbases. 

(21)  Block  30.  Calculate  the  fuel  consumed  in  flight  between  the 
two  airbases. 

(22)  Block  31.  Calculate  the  time  the  escort  mission  unit  must 
arrive  at  the  transport  airbase  in  order  to  arrive  at  the  pickup  point  as 
scheduled. 

(23)  Block  32.  Schedule  an  event  for  the  escort  mission  unit  to 
arrive  at  the  transport  airbase. 

(24)  Block  L430.  Call  routine  PENRAT  to  determine  if  the  pickup 
point  is  on  the  enemy  side  of  the  forward  edge  of  battle  area  (FEBA) . 

(25)  Block  33.  If  the  pickup  point  penetrates  the  FEBA,  control 
goes  to  block  L435;  otherwise,  flow  continues  to  block  L432. 

(26)  Block  L432.  Calculate  the  distance  from  the  airbase  to  the 
pickup  point. 

(27)  Block  L435.  Calculate  the  distance  from  the  airbase  to  a 
safe  point  (penetration)  on  the  friendly  side  of  the  FEBA. 

(28)  Block  L450.  Calculate  the  aircraft  fuel  consumption  over 
the  distance  to  be  moved. 

(29)  Block  L460.  Schedule  an  event  to  arrive  at  either  the 
pickup  point  for  nonpenetration  or  the  safe  point  for  penetration.  If  the 
latter  occurred  the  in-flight  attrition  routines  will  be  activated  to  compute 
aircraft  attrition  over  that  portion  of  the  flight  in  enemy  airspace. 

(30)  Block  L575.  Place  the  mission  unit(s)  unit  status  record (s) 
on  data  file  1. 
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5. 


ROUTINE  ACCPT2 : 


a.  Purpose.  Routine  ACCPT2  is  called  when  tvo  airbases  were  selected 
to  supply  the  requested  airmobile  mission  resources.  Two  mission  units  were 
created  in  ACCPT1,  one  containing  escort  aircraft  and  related  resources,  the 
other  containing  the  transport  aircraft  and  resources.  After  the  escort 
mission  unit  has  flown  to  the  transport  airbase  ACCPT2  merges  the  two 
mission  units  into  one  and  releases  the  other.  The  airmobile  mission  then 
proceeds  toward  the  pickup  point. 

b.  Input  Variables: 

(1)  Standard  Common  Block. 

(2)  Other  Variables: 


Name 

Source 

Contents 

IPICKT 

TWO 

Time  to  arrive  at  pickup  point. 

IDESC 

TWO 

Escort  mission  unit. 

IDTRAN 

TWO 

Transport  mission  unit. 

FUEL 

TWO 

Fuel  consumed  in  flight  to  the  airbase. 

c. 

Output  Variables: 

(1) 

Standard  Common 

Block. 

(2) 

Other  Variables 

Name 

Destination 

Contents 

IDMSTR 

TWO 

Mission  unit  containing  both  escort  and 
port  aircraft. 

FUEL 

TWO 

Fuel  consumed  for  next  leg  of  the  flight 

d. 

Logical  Flow  (Figure 

IV-15-B-A) : 

(1)  Block  1.  Read  the  unit  status  records  of  the  escort  and 
transport  mission  units  from  data  file  1. 

(2)  Block  2.  Update  the  coordinates  of  the  escort  mission  unit  to 
those  of  the  airbase. 

(3)  Block  3.  Transfer  transport  aircraft  and  all  related  resources 
from  the  transport  mission  unit  to  the  escort  mission  unit. 

(A)  Block  L100.  Release  the  transport  mission  unit  and  put  its 
updated  unit  status  record  back  on  data  file  1. 
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Figure  IV-15-B-4. 


Routine  ACCPT2  (Continued  on  Next  Page) 
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Figure  IV-15-B-4.  Routine  ACCPT2  (Concluded) 
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(5)  Block  4.  Calculate  the  fuel  to  be  consumed  during  the  flight 
from  the  transport  airbase  to  the  pickup  point. 

(6)  Block  5.  A  call  to  routine  PENRAT  determines  whether  the 
pickup  point  is  on  the  enemy  side  of  the  FEBA,  which  requires  penetration 
of  enemy  air  space  by  the  mission  unit. 

(7)  Block  6.  A  check  is  made  to  determine  whether  penetration  of 
enemy  air  space  is  necessary. 

(8)  Block  7.  If  there  is  no  penetration,  an  event  for  the  mission 
unit  to  arrive  at  the  pickup  point  is  scheduled. 


(9)  Block  8.  If  there  is  penetration,  an  event  is  scheduled  for 
the  mission  unit  to  arrive  at  a  safe  point  on  the  friendly  side  of  the  FEBA. 
At  this  point  in-flight  attrition  will  begin  and  continue  until  arrival  at 
the  pickup  point. 

(10)  Block  9.  Put  the  mission  unit's  status  record  on  data  file  1. 
6.  ROUTINE  ACCPT3: 


a.  Purpose.  ACCPT3  merges  the  aircraft  and  related  resources  from  the 
mission  unit,  after  its  arrival  at  the  pickup  point,  with  the  unit  to  be 
transported. 

b.  Input  Variables: 


(1)  Standard  Common  Block  Areas.  UMAIN,  UCOOP. 

(2)  Other  Variables: 


Name 

Source 

Contents 

IUIDTP 

TWO 

Unit  to  be  transported. 

IDMSTR 

TWO 

Air  mission  unit. 

FUEL 

TWO 

Fuel  consumed  during  last  leg  of  flight. 

c.  Output  Variables.  Standard  Common  Block  Areas.  UMAIN,  UCOOP. 

d.  Logical  Flow  (Figure  IV-15-B-5) : 

(1)  Block  1.  Read  the  air  mission  unit's  status  record  from  data 


file  1. 


(2)  Block  2.  Read  the  unit  status  record  for  the  unit  to  be 
transported  from  data  file  1. 

(3)  Block  3.  Merge  mission  unit  and  unit  to  be  transported. 
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Figure  IV-15-B-5.  Routine 


ACCPT3 
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(4)  Block  L40O.  Clear  the  mission  unit's  status  record  and  replace 
it  on  data  file  1. 

(5)  Block  4.  Put  transported  unit's  updated  status  record  back  on 
data  file  1. 

7.  ROUTINE  ASULT: 


a.  Purpose, 
assault  segment. 

,  ASULT  is 
It  calls 

the  executive  driver  routine  of  the  Airmobile  Model 
the  proper  routine  to  process  each  assault  event. 

b.  Input  Variables, 
routines . 

These  variables 

;  are  common  to  all  ASULT  segment 

Name 

Source 

Contents 

FILE12 (35) 

DF12 

Event  description  record. 

10  PER 

FILE12 (1) . 

Operation  code. 

IUIDMU 

FILE12  (2) . 
unit. 

Unit  identification  of  assaulting 

IUIDMP 

FILE12 (3) . 
pickup  zone. 

Unit  identification  of  unit  at 

IUIDMS 

FILE12  (4) . 

Unit  identification  of  shuttle  unit. 

IUIDML 

FILE12(5).  Unit  identification  of  unit  at 
landing  zone. 

PZX 

FILE12 (6) . 

Pickup  zone  X  coordinate. 

LEGX  (4) 

FILE12  (7) . 

Flight  leg  end  point  X  coordinates. 

PZY 

FILE12 (11)  . 

Pickup  zone  Y  coordinate. 

LEGY  (4) 

FILE12 (12) . 

Flight  leg  end  point  Y  coordinates. 

FLTIME 

FILE12 (16) . 

Total  one-way  flight  time. 

LATIME 

FILE12 (17) . 

Landing  time. 

ESFUEL 

FILE12 (20) . 
rate. 

Escort  aircraft  fuel  consumption 

TRFUEL 

FILE12 (21) . 
rate. 

Transport  aircraft  fuel  consumption 

LEGCNT 

FILE12 (22) . 

Number  of  flight  legs. 

LEGPT 

FILE12 (23) . 

Flight  leg  being  flown. 
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Name 


Source 


Contents 


XAFTER 

YAFTER 

NXTOPR 


FILE12(33).  Refuel/rearm  return  point 
X  coordinate. 

FILE12(34).  Refuel/rearm  return  point 
Y  coordinate. 

FILE12(35).  Refuel/rearm  and  in-flight  attrition. 
Return  operation  code. 


c.  Output  Variables.  None. 

d.  Logical  Flow  (Figure  IV-15-B-6) : 

(1)  Block  1.  The  value  of  the  operation  code  indicates  which 
routine  is  to  be  called  for  the  current  event. 


(2)  Blocks  LI,  L2,  L3,  and  L4.  One  of  the  four  assault  event 
processing  routines  is  called.  After  the  event  has  been  processed,  control 
returns  to  routine  AMBLEX. 


8.  ROUTINE  ASULT1 : 


a.  Purpose.  ASULT1  is  called  by  routine  ASULT  to  initialize  each 
airmobile  assault  event  sequence.  Its  three  principal  functions  are  to: 

(1)  assemble  the  list  of  flight  leg  coordinates  contained  in  the 
DSL  airmobile  assault  order  and  place  them  on  the  data  file  12 
event  record. 

(2)  assemble  pertinent  constant  data  and  place  them  on  the  data 
file  12  record. 

(3)  schedule  the  event  to  take  off  from  the  pickup  zone  to  arrive 
on  schedule  at  the  landing  zone. 

b.  Input  Variables: 

(1)  Standard  Common  Block  Areas.  UMAIN,  TCLOCK. 

(2)  Other  Variables: 


Name 

Source 

Contents 

ACAVL ( 72 ) 

DF26 

Aircraft  type/time  code  reference. 

VELTAB(36) 

DF26 

Aircraft  velocity  table.  (Same  as  FLTSPD) 

CONSMP(IO) 

DF14 

Fuel  consumption  rate  table. 

FILE12 (35) 

TWO 

Event  description  record. 
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c.  Output  Variables: 


(1) 

Standard  Common 

Block  Area.  UMAIN. 

(2) 

Other  Variables: 

Name 

Destination 

Contents 

FILE12 (35) 

DF12 

Event  description  record. 

d.  Logical  Flow  (Figure 

IV-15-B-7) : 

(1)  Block.  L10.  The  flight  leg  coordinate  points  contained  in  the 
DSL  order  are  passed  to  the  model  by  routine  DOSR.  The  coordinates  are 
placed  in  OBJX,  OBJY  on  the  unit's  status  record.  The  first  coordinate  pair 
is  in  those  locations  when  processing  by  this  routine  begins.  A  value  of 

-1  in  NTIME  indicates  that  more  coordinate  pairs  are  contained  in  the  order. 
Sequential  calls  to  routine  DOSR  cause  each  succeeding  coordinate  pair  to  be 
passed  through  OBJX,  OBJY.  When  the  contents  of  NTIME  are  no  longer  negative, 
DOSR  is  not  called.  The  coordinates  are  transferred  to  LEGX(4) ,LEGY(4)  on 
the  data  file  12  array.  If  more  than  four  coordinate  pairs  are  encountered, 
an  error  message  is  printed  and  processing  terminates.  The  content  of  NTIME 
is  the  desired  time  of  arrival  at  the  landing  zone.  A  value  of  zero  in 
NTIME  indicates  that  the  assault  is  to  begin  immediately. 

(2)  Block  1.  Routine  WETTHR  is  called  to  determine  the  weather/ 
visibility  index  (0  to  3)  which  governs  the  aircraft  flight  speed. 

(3)  Block  L43.  The  aircraft  item  codes  contained  in  the  AIRDAT 
array  are  converted  to  aircraft  type  indices  (1  to  9)  by  searching  the 
ACAVL  table  for  corresponding  codes  on  both  escort  and  transport  aircraft. 

The  item  codes  had  been  entered  into  AIRDAT  when  the  unit  received  an  accept 
transport  order. 

(4)  Block  2.  The  transport  aircraft  flight  speed  is  taken  from  the 
VELTAB  array  for  the  weather/visibility  condition  determined  in  block  1 

and  transport  aircraft  type  index  determined  in  block  L43.  The  transport 
aircraft  fuel  consumption  rate  is  taken  from  the  CONSMP  table  for  the 
flight  speed  which  was  determined  above.  Altitude  of  50  feet  is  assumed. 

(5)  Block  3.  If  no  escort  aircraft  are  present,  block  L47  is  omitted. 

(6)  Block  L47.  Same  as  block  2  excepting  for  escort  aircraft 
instead  of  transport  aircraft. 

(7)  Block  L49.  The  flight  speed  of  the  combined  unit  is  set  to 
the  minimum  of  the  transport  and  escort  speeds. 

(8)  Block  L50.  The  total  flight  time  from  pickup  to  landing  zone 
is  calculated  using  the  speed  determined  in  block  L49  and  the  flight  legs 
determined  in  block  L10.  (Aircraft  landing  time  is  added  to  the  flight 
time  but  the  landing  times  are  not  currently  available.) 
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(9)  Block  4.  Data  assembled  are  saved  in  the  data  file  12  array. 
The  takeoff  time  is  calculated  using  the  flight  time  and  the  requested 
arrival  time.  The  takeoff  event  is  scheduled  by  calling  routine  EVTSET 
which  enters  the  event  in  the  event  table  and  puts  the  data  file  12  array 
onto  data  file  12.  The  takeoff  event  will  be  processed  by  routine  ASULT2. 

9.  ROUTINE  ASULT2 : 

a.  Purpose.  ASULT2  is  called  by  routine  ASULT  at  the  scheduled  takeoff 
time.  The  functions  of  this  routine  are  to  load  the  shuttle  unit  with  the 
correct  quantities  of  personnel  and  equipment  and  to  schedule  the  initiation 
of  the  first  flight  leg.  It  is  also  called  to  load  subsequent  trips.  A 
holding  mission  unit  is  created  when  it  is  necessary  to  leave  some  equipment 
or  personnel  at  the  pickup  zone  for  subsequent  trip(s). 


b.  Input  Variables: 


(1) 

Standard  Common 

Block  Area.  UMAIN. 

(2) 

Other  Variables ; 

Name 

Source 

Contents 

FILE12(35) 

TWO 

Event  description  record. 

TRANWV (3,50) 

DF11 

Transport  weight  and  volume  capacities. 

EQPWV (11 ,233) 

DF11 

Equipment  weight  and  volume. 

EXCL(50) 

DF7 

Secondary  priority  equipment  indicators.  Four 
indicators  per  word. 

EEQPT  (100) 

EQUIPT 

Equipment  type  codes.  Four  codes  per  word. 

MIXTAB(12) 

DF7 

Airmobile  equipment  mix  table. 

c.  Output  Variables: 

Name 

Destination 

Contents 

FILE12 (35) 

DF12 

Event  description  record. 

d.  Logical  Flow  (Figure  IV-15-B-8)  : 

(1)  Blocks  1,  1A,  IB.  The  transport  capacity  table  (TRANWV)  is 
taken  from  data  file  11  and  searched  to  find  the  capacity  of  the  transport 
aircraft  presently  assigned  to  the  unit  being  moved.  If  the  transport  type 
is  not  contained  on  the  table,  an  error  message  is  printed  and  the  job  is 
terminated.  If  found,  the  total  weight  and  volume  capacities  of  the  trans¬ 
ports  available  to  the  unit  are  calculated.  If  no  transport  aircraft  are 
present,  the  event  is  rescheduled  to  1  minute  later. 
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Figure  IV-15-B-8.  Routine  ASULT2  (Continued  on  Next  Page) 
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Figure  IV-15-B-8.  Routine  ASULT2  (Continued) 
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Figure  IV-15-B-8.  Routine  ASULT2  (Concluded) 
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(2)  Block  L20.  The  equipment  weight  and  volume  table  (EQPWV)  is 
taken  from  data  file  11  and  the  equipment  type  codes  (EOHC)  are  taken  from 
COMMON  EQUIPT.  The  EOHC  entries  for  each  aircraft  type,  aircraft  munitions, 
and  class  IIIA  fuel  are  set  to  M.  The  total  weight  and  volume  of  all 
equipment  currently  at  the  pickup  zone  not  coded  with  an  M  are  determined. 

(3)  Block  2.  The  total  weight  and  volume  of  all  secondary  priority 

equipment  at  the  pickup  zone  not  coded  with  an  M  are  also  calculated. 

(4)  Block  3.  The  weight  and  volume  of  all  personnel  at  the  pickup 
zone,  excluding  the  aircraft  crews,  are  calculated. 

(5)  Block  4.  If  the  entire  load  cannot  be  moved  during  this  trip, 
control  branches  to  block  L100;  otherwise,  control  goes  to  block  5. 

(6)  Block  5.  If  this  is  the  only  trip  to  be  made,  control  goes  to 
block  7;  otherwise,  control  goes  to  block  L45. 

(7)  Block  L45.  If  this  is  not  the  only  trip,  the  unit  at  the  pickup 

zone  is  a  holding  mission  unit.  All  personnel  and  equipment  in  the  holding 
mission  unit  are  transferred  to  the  shuttle  mission  unit. 

(8)  Block  L50.  The  status  record  of  the  holding  mission  unit,  no 

longer  required,  is  cleared  and  the  unit  becomes  available  for  other  events. 

(9)  Block  L100.  If  this  is  not  the  first  trip,  a  holding  mission 
unit  exists.  Block  L102  is  omitted. 

(10)  Block  L102.  A  holding  mission  unit  is  created  and  equipment 
not  coded  M  is  transferred  from  the  moving  unit  to  the  holding  mission  unit. 

(11)  Block  L121.  The  fraction  of  the  personnel  and  the  first 
priority  equipment  which  can  be  moved  during  this  trip  is  calculated.  It 
is  the  minimum  of  the  fractional  volume  and  fractional  weight  capabilities. 
The  amount  of  each  first  priority  equipment  type  in  the  holding  mission 
unit  is  prorated  by  the  fraction  and  transferred  to  the  shuttle  unit.  (On 
the  first  trip,  the  shuttle  unit  is  the  unit  ordered  to  perform  the  assault. 
On  following  trips,  it  is  a  mission  unit.) 

(12)  Block  L130.  The  number  of  personnel  in  the  holding  mission 
unit  is  also  prorated  by  the  same  fraction  and  transferred  to  the  shuttle 
unit. 


(13)  Block  6.  If  there  is  no  remaining  lift  capacity,  block  L145 
is  omitted. 

(14)  Block  L145.  The  procedure  explained  in  block  L121  (paragraph 
d(ll)  above)  is  repeated  for  that  quantity  of  secondary  priority  equipment 
which  can  also  be  lifted  on  this  trip. 


t 


(15)  Block  7.  The  event  to  initiate  the  first  flight  leg  is 
described  in  the  data  file  12  array  and  scheduled  to  occur  immediately  by 
setting  IFNT  (56,1)  to  a  value  of  one. 
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10.  ROUTINE  ASULT3 : 


a.  Purpose.  ASULT3  regulates  the  movement  of  the  shuttle  unit  between 
the  pickup  and  landing  zones.  It  schedules  in-flight  attrition  events  for 
each  flight  leg,  ASULT2  and  ASULT4  events  upon  arrival  at  the  pickup  and 
landing  zones  respectively,  and  refuel/rearm  events  when  appropriate. 

b.  Input  Variables: 


(1) 

(2) 


Name 

FILE12 (35) 
MIXTAB (12) 


Standard  Common  Block  Area.  UMAIN. 

Other  Variables: 

Source  Contents 

DF12  Event  description  record. 

DF07  Airmobile  mix  table. 


c.  Output  Variables: 


(1) 

Standard  Common  Block  Areas.  UMAIN,  UNTLOC 

(2) 

Other  Variables: 

Name 

Destination 

Contents 

FILE12 (35) 

DF12  Event  description 

record. 

d.  Logical  Flow  (Figure  IV-15-B-9) : 

(1)  Block  1.  If  the  shuttle  unit  is  leaving  the  landing  zone  on  a 
return  flight  and  the  landing  zone  is  in  friendly  territory,  control  goes 
to  block  L250  to  determine  if  the  unit  needs  refueling  and  rearming.  A 
jump  flag  is  set  to  return  control  if  the  unit  does  not  need  refueling  and 
rearming. 

(2)  Block  2.  If  the  unit  is  in  the  process  of  leaving  the  landing 
or  pickup  zone,  blocks  3  and  4  are  omitted,  and  the  leg  pointer  has  a  value 
of  0  or  -1. 


(3)  Block  3.  The  time  of  flight  of  the  preceding  leg  is  determined  * 

from  the  distance  flown  and  the  airspeed.  The  rate  of  fuel  consumption 

for  escort  aircraft  and  transport  aircraft  is  calculated  and  subtracted  from 
the  quantity  of  fuel  on  board. 

» 

(4)  Block  4.  The  location  of  the  shuttle  unit  is  updated  on  the 

unit  status  record  and  the  location  table  in  common.  ■> 

(5)  Block  L101.  If  the  flight  is  toward  the  landing  zone,  the  leg 
pointer  is  incremented.  If  it  is  toward  the  pickup  zone,  the  leg  pointer  is 
decremented.  This  pointer  identifies  the  flight  leg  to  be  flown. 

4»» 
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Figure  IV-15-B-9.  Routine  ASULT3  (Concluded) 
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(6)  Block  5.  If  Che  leg  pointer  has  a  value  of  zero  or  if  it 
exceeds  the  number  of  legs  in  the  assault,  the  unit  has  arrived  at  the  landing 
or  pickup  zone  and  control  goes  to  block  L200. 

(7)  Block  6.  The  altitude  is  fixed  at  50  feet  and  the  value  of 
MEVTX  and  MEVTY  on  the  unit  status  record  are  set  to  the  coordinate  of  the 
end  point  of  the  flight  leg  to  be  flown. 

(8)  Block  7.  The  in-flight  attrition  operation  code  is  set  and 
IFNT(56,1)  is  set  to  one  to  initiate  that  event  immediately.  Control  transfers 
to  block  L300. 

(9)  Block  L200.  If  the  shuttle  unit  has  arrived  at  the  landing 
zone,  control  goes  to  block  L205.  If  it  has  arrived  at  the  pickup  zone, 
control  continues  to  block  8. 

(10)  Block  8.  If  the  unit  has  arrived  at  the  pickup  zone  and  the 
landing  zone  is  in  enemy  territory,  a  refuel/rearm  check  is  made,  with  the 
jump  flag  set  to  cause  control  to  go  to  block  11  and  control  goes  to  block 
L250.  Otherwise,  control  goes  directly  to  block  11. 

(11)  Block  L250.  The  length  of  time  that  the  unit  can  fly  with 
the  fuel  presently  on  board  is  calculated  from  the  consumption  rates. 

(12)  Block  9.  The  time  required  to  fly  all  flight  legs  is  added 
to  the  landing  time. 

(13)  Block  10.  If  the  unit  cannot  fly  a  complete  round  trip  with 
30  minutes  reserve,  control  goes  to  block  L400  to  schedule  a  refuel/rearm 
event . 


(14)  Block  L210.  The  mix  table  is  read  from  data  file  7  and 
the  full  load  of  munitions  for  the  current  number  of  escort  aircraft  is 
calculated.  If  the  unit  has  less  than  half  of  the  full  load,  control  goes 
to  block  L400. 

(15)  Block  L400.  The  return  location  on  the  data  file  12  array  is 
set  to  the  current  location  of  the  unit.  The  refuel/rearm  operation  code 
is  set  and  the  return  operation  code  is  set.  The  content  of  IFNT(56,1)  is 
set  to  one  to  cause  the  event  to  be  initiated  immediately. 

(16)  Block  L220.  If  the  refuel/rearm  check  was  made  for  a  unit 
leaving  the  landing  zone  (jump  flag  equals  0)  control  goes  to  block  2. 

(17)  Block  11.  The  unit  has  returned  to  the  pickup  zone  for 
another  load  and  trip.  The  ASULT2  operation  code  is  set  and  IFNT(56,1)  is 
set  to  one  to  cause  the  event  to  be  initiated  immediately. 

(18)  Block  L300.  The  unit  status  record  of  the  shuttle  unit  is 
returned  to  data  file  1. 
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a.  Purpose.  ASULT4  controls  the  unloading  of  personnel  and  equipment 
at  the  landing  zone  and  the  consolidation  of  the  unit.  It  also  initiates 

the  event  sequence  to  return  the  aircraft  to  the  pickup  zone  for  any  additional 
required  trip  loads. 

b.  Input  Variables: 


(1) 

Standard  Common 

Block  Areas.  UMAIN,  UCOOP, 

TCLOCK 

(2) 

Other  Variables 

: 

Name 

Source 

Contents 

FILE12 (35) 

DF12 

Event  description  record. 

MIXTAB(12) 

DF07 

Airmobile  mix  table. 

FEBXIN 

ZONDAT 

FEBA  intercept  with  X  axis. 

IANGL 

DF16 

Force  orientation  angle. 

c.  Output  Variables: 

(1) 

Standard  Common 

Block  Areas.  UMAIN,  UCOOP, 

UNTLOC 

(2) 

Other  Variables 

: 

Name 

Destination 

Contents 

FILE12 (35) 

DF12 

Event  description  record. 

d.  L_gical  Flow  (Figure  IV-15-B-10): 

(1)  Block  1.  If  there  is  a  nonzero  value  in  IUIDML,  part  of  the 
unit  has  arrived  on  a  previous  trip.  Control  then  goes  to  block  L500; 
otherwise,  control  goes  to  block  2. 

(2)  Block  2.  The  unit  being  moved  is  given  a  stay  event  for  zero 
time.  This  causes  the  unit  to  resume  its  ordered  event  cycle. 

(3)  Block  3.  The  X  axis  intercept  of  a  line  passing  along  the 
foward  edge  of  the  unit  and  parallel  to  the  FEBA  is  calculated.  The  X 
intercept  of  that  line  is  compared  with  FE3XIN  to  determine  if  the  unit 
is  across  the  FEBA  from  the  remainder  of  its  force. 

(4)  Block  4.  If  the  unit  is  across  the  FEBA,  AMBLFG  is  set  to 
one;  otherwise,  it  is  set  to  zero.  If  some  of  the  unit  is  still  at  the 
pickup  zone  (IUIDMP  contains  a  nonzero  value),  AMBLFG  is  decremented  by  two. 
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Figure  IV-15-B-10.  Routine  ASULT4  (Continued  on  Next  Page) 
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Figure  IV-15-B-10.  Routine  ASULT4  (Continued) 
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Figure  IV-15-B-10.  Routine  ASULT4  (Concluded) 
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(5)  Block  5.  If  none  of  the  unit  is  still  at  the  pickup  zone, 
control  goes  to  block  L105;  otherwise,  control  goes  to  block  L10. 

(6)  Block  L10.  The  unit  being  moved  will  remain  at  the  landing 
zone.  A  shuttle  mission  unit  is  created  to  simulate  subsequent  trips  between 
the  pickup  and  landing  zones. 

(7)  Block  L35.  All  aircraft,  munitions,  and  class  IIIA  fuel  are 
transferred  from  the  unit  at  the  landing  zone  to  the  shuttle  mission  unit. 

The  required  number  of  personnel  for  the  aircraft  crews  is  also  transferred. 
The  number  and  types  of  equipment  are  obtained  from  the  mix  table. 

(8)  Block  L100.  The  operation  code  is  set  to  24  for  the  ASULT3 
event.  The  leg  pointer  is  initialized  to  zero  and  IFNT(56,1)  is  set  to  one 
to  cause  the  event  to  be  initiated  immediately. 

(9)  Block  L105.  The  applicable  unit  status  records  are  restored 
onto  data  file  1. 

(10)  Block  1500.  This  is  a  subsequent  trip.  The  status  records 
of  the  shuttle  mission  unit  and  the  unit  at  the  landing  zone  are  read  into 
common  and  all  personnel  and  equipment  in  the  shuttle  unit  are  transferred 
to  the  unit  at  the  landing  zone. 

(11)  Block  6.  If  additional  trips  are  to  be  made,  control  goes  to 
block  L35. 

(12)  Block  L520.  The  status  record  of  the  shuttle  mission  unit  is 
cleared  and  the  unit  is  available  for  use  by  another  event  sequence. 

(13)  Block  7.  The  value  of  AMBLFG  on  the  unit  being  moved  is 
incremented  by  two  to  indicate  that  it  is  no  longer  en  route. 

(14)  Block  8.  If  the  unit  has  a  join  or  detach  order  pending,  the 
unit  is  given  a  stay  event  to  enable  it  to  resume  its  ordered  event  cycle. 

12.  COMMON  BLOCK  FRRA: 

a.  Purpose.  Common  block  FRRA  contains  variables  which  are  used  in 

the  forward  refuel/rearm  segment  of  the  Airmobile  Model.  Most  FRRA  variables 
are  equivalenced  to  IDUM;  however,  some  variables  are  equivalenced  to  UMAIN. 
The  working  portion  of  FRRA  (work)  is  stored  in  data  file  24. 

b.  Variables: 


Name 

IUIDMU(20) 
TIF (20) 


Equivalenced 

to _  Description 

W0RK(1)  IUID  of  mission  unit. 

W0RK(21)  Total  number  of  inlets  to  be  refueled. 
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Equivalenced 


Name 

to 

Description 

TACRA (20) 

WORK(41) 

Total  number  of  aircraft  to  be  rearmed. 

READY (20) 

WORK (61) 

Number  of  aircraft  ready  to  be  rearmed. 

TAC(20) 

WORK(81) 

Time  required  to  rearm  one  aircraft  of  this 
flight. 

RFTPI(20) 

WORK(lOl) 

Refuel  time  per  inlet. 

RACAT (100) 

WORK(121) 

Rearm  capacity  availability  times. 

RACAA(IOO) 

WORK(221) 

Amount  of  rearm  capacity  available  at  time  RACAT. 

RFC 

WOt»K(321) 

FRRA  refuel  capacity. 

RAC 

WORK (322) 

FRRA  rearm  capacity. 

QI 

WORK (32 3) 

Queue  index. 

RFP 

WORK(324) 

Refuel  index. 

RAP 

WORK(325) 

Rearm  index. 

TLTFC 

WORK(326) 

Total  amount  of  fuel  committed  to  units.  Long¬ 
term  fuel,  incremented  as  units  are  assigned  to 
FRRA. 

TSTFC 

WORK (32 7) 

Short-term  fuel  committed  to  units,  incremented 
as  units  begin  refueling. 

MTRF 

WORK(328) 

Maneuver  time  for  refueling. 

MIRA 

WORK(329) 

Maneuver  time  for  rearming. 

WORK (330) 

Pointer  to  the  last  record  used  on  data  file  24 
(stored  in  record  1). 

IOPR 

KDUM(L) 

Numeric  operator  code;  indicates  unit's 
refuel/rearm  status. 

MU  ID 

KDUM(2) 

IUID  of  mission  unit. 

TRL 

KDUM(3) 

Rearm  time  pointer  (RACAT,  RACAA) . 

IUIDA 

KDUM(4) 

IUID  of  mission  unit  (same  as  MUID) . 

LTFL 

KDUM(5) 

Long-term  fuel  committed  to  unit. 

STFC 

KDUM(6) 

Short-term  fuel  committed  to  unit. 
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Name 

Equivalenced 

to 

Description 

IUIDF 

KDUM(7) 

IUID  of  FRRA. 

AC  BP 

KDUM(31) 

Number  of  aircraft  being  processed. 

IRETX 

KDUM(33) 

Return  X  coordinate. 

IRETY 

KDUM (34) 

Return  Y  coordinate. 

IOPRET 

KDUM(35) 

Next  IOPR  of  mission  unit. 

CONSUM 

IDUM(21) 

Aircraft  fuel  consumption  rates  from  data  file  14. 

MIXTAB 

IDUM(29) 

Airmobile  mix  table  from  data  file  7. 

KDUM 

IDUM(94) 

Automatic  event  order  table. 

WORK 

IDUM(151) 

FRRA  working  array  described  above. 

DMU 

NOR 

Mission  unit  index. 

FCOMP 

OBJX 

Number  of  fuel  inlets  remaining  to  be  refueled. 

ACOMP 

OBJY 

Number  of  aircraft  for  a  particular  mission  unit 
which  remain  to  be  rearmed. 

PRSRFP 

DGZX 

Number  of  refuel  points  currently  available. 

PRSRAP 

DGZY 

Number  of  rearm  points  currently  available. 

NAUTRA 

MUNTPY 

Number  of  authorized  rearm  points. 

MIX 

AIRDAT (8) 

Pointer  to  the  mix  table  associated  with 
this  unit. 

CPRSRF 

CDGZX 

Number  of  refuel  points  currently  available. 

CPRSRA 

CDGZY 

Number  of  rearm  points  currently  available. 

CNAURA 

CMUNTP 

Number  of  authorized  rearm  points. 

13.  ROUTINE  RREXEC: 

a. 

Purpose.  This  routine  is  the  executive  routine  of  the  refuel/rearm 

part  of  the  Airmobile  Model.  Routines  RRFRRA,  RRQUE,  RRTURN,  and  RRFLD  are 
all  called  by  this  routine.  RRFLD  calls  REFUEL  and  RATIM. 

b.  Input  Variables.  Standard  common  block,  FRRA. 
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c.  Output  Variables.  None 

d.  Logical  Flow  (Figure  IV-15-B-11) : 

(1)  IOPR  =  40.  When  this  event  occurs,  the  aircraft  mission  unit 
could  find  no  forward  refueling/rearming  areas  (FRRA)  available  on  its  last 
attempt.  Either  the  FRRA  was  moving  to  a  new  location  or  it  was  under 
enemy  attack.  The  unit  has  waited  5  minutes  and  is  trying  again. 

(2)  IOPR  =  41.  When  this  event  occurs,  the  aircraft  mission  unit 
is  making  its  first  search  for  FRRAs.  It  first  tries  to  find  FRRA  which 
is  in  direct  support  to  the  mission  unit.  The  second  choice  is  FRRA  in 
general  support.  The  last  choice  is  a  FRRA  in  direct  support  to  other  units. 
The  time  when  the  flight  will  arrive  at  the  selected  FRRA  is  also  calculated. 

(3)  IOPR  =  42.  This  event  occurs  as  the  flight  arrives  at  the 
FRRA.  The  flight  is  either  put  into  a  holding  area  or  is  put  in  a  refueling 
queue.  If  the  flight  is  put  in  a  holding  area,  an  IOPR  =  45  event  is 
scheduled  to  occur  in  5  minutes. 

(4)  IOPR  =  43.  Part  of  a  flight  has  just  completed  refueling. 

Those  aircraft  that  have  been  refueled  are  put  into  a  rearming  queue  or 
into  a  holding  area  if  no  rearming  is  required.  If  additional  aircraft  in 
this  flight  need  fuel,  the  refueling  is  scheduled;  otherwise,  the  next  flight 
in  the  refuel  queue  is  examined. 

(5)  IOPR  =  44.  Part  of  a  flight  has  just  completed  rearming.  Those 
aircraft  that  have  been  rearmed  are  put  into  a  holding  area.  If  all  aircraft 
have  completed  refueling  and  rearming,  an  IOPR  «>  49  event  is  scheduled.  If 
additional  aircraft  need  rearming,  the  rearming  is  scheduled. 

(6)  IOPR  =  45.  When  the  flight  first  arrived  at  the  FRRA,  the 
refueling  queue  was  full.  The  flight  was  diverted  to  a  holding  area.  After 
a  5-minute  delay,  the  flight  is  trying  again. 

(7)  IOPR  =  46.  The  flight  is  in  queue  and  requesting  refueling. 

The  refuel  capacity  of  the  FRRA  has  been  saturated  until  the  present  time. 

(8)  IOPR  =  47.  The  flight  is  in  rearming  queue  and  requesting 
rearming. 

(9)  IOPR  =  48.  Not  used. 

(10)  IOPR  =  49.  Flight  has  completed  refueling  and  rearming.  It 
has  now  flown  from  the  FRRA  to  its  next  objective. 

14.  ROUTINE  RRFRRA : 

a.  Purpose.  When  a  unit  requests  refueling  and  rearming  services,  this 
routine  selects  a  forward  refueling  and  rearming  area  (FRRA)  and  sends  th ; 
unit  to  the  FRRA.  A  unit's  initial  request  enters  RRFRRA  with  IOPR  equals 
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IOPR 


ROUTINE  CALLED 


40 

RRFRRA 

42,  45 

RRQUE 

'IHgKJl 

RRFLD 

49 

RRTURN 

41.  Subsequent  requests  by  the  same  unit  enter  with  IOPR  equals  40.  The 
routine  attempts  to  locate  FRRA  for  the  requesting  mission  unit  in  the 
following  sequence: 


in  direct  support  of  the  mission  unit  or  its  superior  unit. 

in  general  support 

in  direct  support  of  another  unit. 


If  these 
another 

three  attempts  fail 
attempt  is  made. 

,  a  5-minute  delay  is  scheduled  after  which 

b. 

Input 

Variables : 

(1) 

Standard  Common 

Areas.  UMAIN,  UCOOP,  FRRA,  UTDTBL,  L'NTLOC 

(2) 

Other  Variables 

Name 

Source 

Contents 

IRRUTD 

DF7 

UTDs  of  FRRA  units. 

CONSUM 

DF14 

Fuel  consumption  rates  of  aircraft. 

IF  7 

DF7 

Refuel  maneuver  time  in  minutes  [IF7(241>] 

IF  7 

Rearm  maneuver  time  in  minutes  [ IF7 (242) ] . 

NN 

DF7 

Number  of  nozzles  on  each  refuel  device. 

IC 

DF7 

Equipment  item  code  of  refuel  device. 

c.  Output  Variables. 

(1)  Standard  common  block  variable:  DELT 

(2)  FRRA  common  block  variables:  RAC,  RFC,  IOPR. 

d.  Logical  Flow  (Figure  IV-15-B-12) : 

(1)  Block  1.  A  unit  entering  RRFRRA  with  IOPR  equals  41  is  making 
an  initial  request  for  refueling  and  rearming  services.  A  unit  entering 
RRFRRA  with  IOPR  equals  40  requested  refueling  and  rearming  services  previously, 
but  no  FRRAs  were  available,  and  the  unit  is  making  another  request.  The 

list  of  possible  FRRA  UTDs  is  read  from  data  file  7. 

(2)  Block  2.  When  an  aircraft  mission  unit  requires  fuel  or 
ammunition,  it  is  determined  whether  the  aircraft  unit  has  an  FRRA  unit 
in  direct  support.  The  mission  unit's  status  record  is  read  from  data 
file  1. 
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Figure  IV-15-B-12.  Routine  RRFRRA  (Continued) 
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Figure  IV-15-B-12.  Routine  RRFRRA  (Continued) 
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(3)  Block  3.  A  check  is  then  made  to  determine  if  any  of  the 
units  in  direct  support  is  an  FRRA. 

(4)  Block  4.  If  at  least  one  direct  support  unit  is  an  FRRA,  control 
passes  to  block  8.  If  none  are,  control  goes  to  block  5. 

(5)  Block  5.  In  this  block  a  check  is  made  to  determine  if  both 
the  mission  unit  and  its  superior  have  been  examined  for  FRRA  direct  support 
units.  If  not,  control  flows  to  block  6.  If  FRRA  units  in  general  support 
have  not  been  examined,  control  flows  to  block  7.  If  all  FRRA  units  have 
been  examined  except  those  in  direct  support  of  other  units,  control  passes 
to  block  14. 

(6)  Block  6.  If  only  the  mission  unit  has  been  examined  and  no 
FRRA  unit  in  direct  support  was  found,  the  superior  of  the  mission  unit  is 
considered.  If  the  IUID  of  the  superior  unit  is  zero,  control  goes  to 
block  15;  otherwise,  the  unit  status  record  is  read  and  control  passes  to 
block  3. 


(7)  Block  7.  If  all  FRRA  units  in  direct  support  to  either  the 
mission  unit  or  its  superior  and  all  FRRA  units  in  general  support  have 
been  examined,  FRRA  units  in  direct  support  to  other  units  are  examined. 
Control  goes  to  block  4. 

(8)  Block  8.  At  least  one  FRRA  candidate  has  been  found.  The 
distances  from  the  FRRA  units  to  the  release  point  from  the  Airmobile 
Model  are  calculated.  For  those  available,  the  FRRA  unit  nearest  to  the 
release  point  is  selected. 

(9)  Block  9.  After  an  FRRA  unit  is  selected,  the  unit  is  examined 
to  determine  if  it  is  in  a  resupply  mode;  i.e.,  stay  order.  If  it  is  not, 
control  passes  to  block  10.  If  it  is,  a  check  is  made  to  determine  if  the 
unit  is  under  fire.  If  the  unit  has  been  assessed  casualties  in  the  last 

5  minutes  it  is  under  fire.  If  it  is  not  under  fire,  control  goes  to  block 
11;  otherwise,  block  10  is  executed. 

(10)  Block  10.  Since  this  FRRA  unit  is  no  longer  a  possible 
candidate,  a  check  is  made  to  determine  if  other  FRRA  units  are  available. 

If  all  FRRA  units  in  this  group  have  been  considered,  control  returns  to 
block  5;  otherwise,  the  next  closest  FRRA  unit  in  this  group  is  selected 
and  control  returns  to  block  9. 

(11)  Block  11.  An  FRRA  unit  has  been  found.  If  IOPR  equal  40,  the 
fuel  that  this  mission  unit  consumed  while  waiting  is  extracted  from  its 
unit  status  record.  A  data  file  24  record  is  assigned  the  FRRA  unit.  This 
record  is  used  to  store  the  FRRA's  refuel  and  rearm  queue  information.  If 
data  file  24  is  too  small,  it  is  expanded  by  10  records.  The  FRRA  unit's 
status  record  and  data  file  24  record  are  put  out  and  control  goes  to 
block  12. 

(12)  Block  12.  The  FRRA  unit's  rearm  and  refuel  maneuver  times  are 
read  from  data  file  7  and  stored  in  the  work  area.  The  number  of  rearm 
points  authorized  to  the  FRRA  is  read  from  data  file  7  and  reduced  by  the 
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ratio  of  current  personnel  strength  of  the  FRRA  unit  to  the  authorized 
personnel  strength.  The  number  of  refuel  nozzles  available  at  the  FRRA 
is  also  calculated.  This  information  is  put  on  data  file  24. 

(13)  Block  13.  The  status  record  of  the  FRRA  unit  is  put  back  on 
the  unit  status  file.  Finally,  the  arrival  of  the  mission  unit  at  the  FRRA 
is  scheduled  and  control  returns  to  the  calling  routine. 

(14)  Block  14.  No  FRRA  units  are  currently  available.  A  5-minute 
delay  is  scheduled  with  IOPR  equal  40.  After  the  delay  has  elapsed,  another 
attempt  will  be  made  to  find  an  FRRA.  The  control  returns  to  the  calling 
routine. 


(15)  Block  15.  FRRA  units  in  direct  support  to  either  the  mission 
unit  or  its  superior  have  been  examined  and  rejected  as  possible  candidates. 
Remaining  FRRA  units  are  now  examined.  Those  FRRA  units  in  general  support 
are  stored  in  array  LSAVE  and  those  in  direct  support  to  other  units  are 
stored  in  JSAVE.  After  all  FRRAs  have  been  considered,  LOCF  is  set  equal 
to  three  and  control  returns  to  block  4. 

15.  ROUTINE  RRQUE: 

a.  Purpose.  This  routine  is  called  when  the  aircraft  mission  unit  that 
requires  refueling/rearming  arrives  at  the  FRRA.  RRQUE  sets  the  parameters 
that  place  the  unit  in  the  refuel  queue.  If  the  queue  is  full,  the  aircraft 
is  scheduled  to  wait  in  a  holding  area  for  30  minutes  to  enter  the  refuel 
queue  again. 

b.  Input  Variables: 

(1)  Standard  Common  Areas.  UMAIN,  UCOOP,  FRRA. 

(2)  Other  Variables: 


Name 

Source 

Contents 

MIXTAB(l) 

DF7 

Equipment  item  code  of  escort  aircraft. 

MIXTAB(3) 

Maximum  amount  of  fuel  on  each  escort  aircraft. 

MIXTAB(4,6,8) 

Equipment  item  codes  of  munitions  loaded  on 
escorts . 

MIXTAB (5,7,9) 

Amounts  of  munitions  loaded  on  escorts 
corresponding  to  munitions  equipment  item  codes. 

MIXTAB(IO) 

Equipment  item  code  of  transport  aircraft. 

MIXTAB (12) 

Maximum  amount  of  fuel  on  each  transport 
aircraft. 

MIXTAB (13) 

Rearm  time  per  escort  aircraft. 
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Name 


Source 


Contents 


MIXTAB (14) 

MIXTAB (15) 

c.  Output  Variables: 

Number  of  escort  refuel  inlets. 

Number  of  transport  refuel  inlets. 

(1) 

FRRA  Common  Block  Variables.  FCOMP,  ACOMP ,  and  ACBP. 

(2) 

Other  Variables 

Name 

Destination 

Contents 

TAV 

Call 

Time  increment  added  to  TCLOCK,  time  when 
flight  fragment  will  be  refueled. 

IDT 

Call 

Same  as  TAV. 

NFUEL 

Call 

Flag  indicating  whether  refueling  can  occur 

at  this  time. 

d.  Logical  Flow  (Figure  IV-15-B-13) : 

(1)  Block  1.  Entry  can  be  initiated  by  either  of  two  events.  Either 
a  mission  unit  is  attempting  to  enter  the  refuel  queue  at  the  FRRA  for  the 
first  time  (IOPR  *  42)  or  the  queue  was  full  the  first  time  and  the  unit  is 
trying  after  a  30-minute  delay  (IOPR  *  45).  In  both  cases,  the  mission  unit's 
status  record  is  read  into  UMAIN,  the  FRRA  unit's  status  record  is  read  into 
UCOOP,  and  the  data  file  24  work  area  for  the  FRRA  is  brought  into  common. 

The  coordinates  of  the  FRRA  unit  are  assigned  to  the  mission  unit. 

(2)  Block  2.  The  fuel  consumed  during  this  flight  as  the  aircraft 
flew  from  the  release  point  to  the  FRRA  or  as  it  waited  to  enter  the  refuel 
queue  is  calculated  and  subtracted  from  the  fuel  on  board  the  aircraft. 

(3)  Block  3.  Before  the  aircraft  unit  can  be  placed  in  the  refuel 
queue,  a  check  determines  if  the  queue  is  full.  Capacity  has  been  set  at 
20.  If  the  queue  is  full,  the  flight  is  diverted  to  a  holding  area  for 

30  minutes.  At  the  end  of  this  time,  another  attempt  will  be  made  by  this 
aircraft  unit  to  enter  the  refuel  queue. 

(4)  Block  4.  If  the  queue  is  not  full,  the  IUID  of  the  mission  unit 
is  entered  in  the  IUIDMU  array.  The  data  file  12  information  is  stored  in 
the  data  file  24  work  area. 

(5)  Block  5.  Since  the  mission  unit  does  not  transfer  its  aircraft 
to  the  FRRA  unit's  status  record,  the  mission  unit  is  assigned  a  width  and 
depth  for  assessment  of  damage  from  artillery  fire.  Aircraft  are  considered 
to  be  uniformly  distributed  in  the  first  (or  front)  band  of  the  rectangle  used 
to  represent  the  unit. 
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Figure  IV-15-B-13.  Routine  RRQUE  (Continued  on  Next  Page) 
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Figure  IV-15-B-13.  Routine  RRQUE  (Concluded) 
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(6)  Block  6.  The  number  of  inlets  to  be  refueled  on  these  aircraft 
are  calculated.  Number  of  inlets  rather  than  number  of  aircraft  are  used 
since  some  aircraft  may  have  more  than  one  fuel  inlet.  An  aircraft  with  two 
inlets  will  be  refueled  faster  than  the  same  aircraft  with  only  one  inlet. 
Number  of  inlets  per  aircraft  is  obtained  from  data  file  7. 

(7)  Block  7.  The  number  of  aircraft  to  be  rearmed  is  based  on  the 
number  of  escort  aircraft  available.  Transport  aircraft  are  not  rearmed. 

Those  escort  aircraft  that  have  expended  at  least  1  percent  of  their  ammuni¬ 
tion  load  are  rearmed. 

(8)  Block  8.  The  rearming  time  for  each  aircraft  in  the  flight  unit 
is  equal  to  the  rearming  time  per  aircraft  from  the  MIXTAB  array  on  data 
file  7  plus  a  maneuver  rearming  time  from  data  file  7.  This  new  rearming 
time  is  stored  in  the  data  file  24  work  array  in  TAC(21).  The  refuel  and 
rearm  counters  are  set  and  stored  in  the  mission  unit's  status  record. 

(9)  Block  9.  A  check  determines  if  there  are  available  refuel 
nozzles  at  the  FRRA.  If  there  are  none,  control  goes  to  block  17. 

(10)  Block  10.  If  refuel  nozzles  are  available,  another  check 
determines  if  rearming  is  required  by  this  flight  unit.  If  it  is,  routine 
RATIM  is  called  to  determine  when  the  rearm  capability  will  be  available. 

(11)  Block  11.  Refuel  time  (in  centiminutes)  per  inlet  is  calculated 
by  dividing  the  number  of  gallons  of  fuel  required  per  inlet  by  the  intake  rate 
of  the  fuel  tanks.  A  constant  intake  rate  of  50  gallons  per  minute  is  assumed. 
A  refueling  maneuver  time  is  added  to  arrive  at  the  refueling  time  per  inlet, 
RFTPI (21) . 

(12)  Block  12.  The  number  of  inlets  to  be  fueled  during  this 
flight  segment  will  be  the  lesser  of  the  available  refuel  nozzles  and  the 
number  of  inlets  that  require  refueling.  The  amount  of  fuel  required  to 
fill  these  inlets  is  calculated.  The  refueling  time  per  inlet  is  subtracted 
from  the  earliest  rearming  time  calculated  in  RATIM  to  determine  when  refuel¬ 
ing  of  this  segment  can  commence.  If  this  time  is  in  the  future,  the  mission 
unit  will  not  begin  refueling  until  that  time  is  reached. 

(13)  Block  13.  If  sufficient  fuel  is  not  available  to  refuel  the 
flight  segment,  a  15-minute  delay  is  scheduled  (I0PR  =  46)  at  which  time 
another  attempt  will  be  made  to  refuel  the  aircraft.  If  the  earliest  refuel¬ 
ing  time  calculated  in  block  12  has  not  been  reached,  a  delay  is  scheduled 
(IOPR  *»  46)  until  that  time.  In  both  these  cases  control  passes  to  block  17. 

(14)  Block  14.  If  refuel  facilities  are  available,  the  mission 
unit's  altitude  is  set  equal  to  zero,  and  NORD  equal  to  one. 

(15)  Block  15.  An  attempt  is  made  to  refuel  this  flight  segment 
by  setting  NFUEL  equal  to  one  and  calling  routine  REFUEL. 

(16)  Block  16.  If  refueling  can  occur,  the  refueling  event  is 
scheduled  with  IOPR  equal  43.  Control  goes  to  block  18;  otherwise,  control 
passes  to  block  17. 
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(17)  Block  17.  If  refueling  cannot  begin  immediately,  NORD  is  set 
equal  to  32  and  NTIME  is  set  equal  to  TCLOCK. 

(18)  Block  18.  The  updated  file  data  are  restored  to  the  files. 

If  the  refuel  queue  was  full,  only  the  mission  unit's  status  record  is  put 
out;  otherwise,  both  the  mission  unit's  status  record  and  its  associated 
data  file  24  work  area  are  put  out- 

16.  ROUTINE  RRFLD : 

a.  Purpose.  This  routine  simulates  the  actual  refueling  and/or  rearming 
of  the  flight  segments.  In  addition  it  schedules  additional  refueling/ 
rearming  of  flight  segments  as  noz2les  and  rearming  points  become  available. 
This  routine  is  entered  when  the  value  of  IOPR  is  equal  to  43,  44,  46,  or  47. 

b.  Input  Variables: 

(1)  Standard  Common  Area:  UMAIN,  UCOOP,  FRRA. 

(2)  Other  Variables: 


Name 

Source 

Contents 

MIXTAB 

DF7 

Information  on 
in  mission  unit 

escort  and  transport 

aircraft 

IC 

DF7 

Equipment  item 

codes  and  number  of 

refueling 

equipment . 

c.  Output  Variables.  FRRA  common  block  variables,  FCOMP,  ACOMP  and  ACBP. 

d.  Logical  Flow  (Figure  IV-15-B-14) : 

(1)  Block  1.  This  block  checks  the  value  of  IOPR  (43,  44,  46,  or  47) 
and  control  is  transferred  appropriately. 

(2)  Block  LA.  A  unit  entered  at  this  point  (IOPR  =  43)  has  completed 
all  or  partial  refueling  The  mission  unit's  status  record  is  brought  from 
data  file  1  and  stored  in  UMAIN,  the  FRRA  unit's  status  record  is  brought  in 
and  stored  in  UCOOP,  and  the  data  file  24  work  area  and  the  airmobile  data 
are  brought  in  from  data  file  24  and  data  file  7  respectively. 

(3)  Block  2.  The  number  of  nozzles  currently  available  to  refuel 
is  recalculated  to  account  for  attrition  and  resupply. 

(4)  Block  3.  The  number  of  inlets  for  this  unit  that  have  not 
been  refueled  are  reduced  by  the  number  of  inlets  that  have  completed 
refueling.  The  resulting  number  is  placed  in  FCOMP  and  stored  on  the  mission 
unit's  status  record. 

(5)  Block  4.  The  number  of  nozzles  that  are  available  to  refuel  is 
increased  by  the  number  of  inlets  that  have  completed  refueling. 
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Figure  IV-15-B-14. 
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figure  IV-15-B-14.  Routine  RRFLD  (Continued) 
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Figure  IV-15-B-14. 


Routine  RRFLD  (Continued) 
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(6)  Block  5.  The  number  of  aircraft  ready  for  rearming  is  increased 
by  the  number  that  have  completed  refueling.  If  the  result  is  greater  than 
the  number  requiring  rearming,  the  value  is  set  equal  to  the  required  number. 
Escort  aircraft  are  assumed  to  have  refueled  prior  to  transport  aircraft. 

(7)  Block  6.  If  all  aircraft  in  the  flight  unit  have  not  completed 
refueling,  control  goes  to  block  8;  otherwise,  the  fuel  required  to  fill  the 
aircraft  is  transferred  from  the  FRRA  unit's  status  record  to  the  mission 
unit's  status  record.  The  mission  unit's  status  record  is  put  back  on  data 
file  1.  Control  goes  to  block  7. 

(8)  Block  7.  If  all  aircraft  in  the  unit  have  not  completed 
rearming,  control  goes  to  block  8;  otherwise,  the  unit  has  completed  refueling 
and  needs  no  rearming.  It  will  be  flown  to  its  next  objective.  Control  goes 
to  block  35. 

(9)  Block  8.  If  scheduling  has  not  been  completed  for  all  inlets 
in  this  unit,  control  goes  block  15;  otherwise,  control  goes  to  block  19. 

(10)  Block  9.  A  mission  unit  enters  at  this  point  (IOPR  =  46) 
because  facilities  were  not  previously  available.  As  in  block  1A,  the  file 
information  is  read  from  the  data  files. 

(11)  Block  10.  A  check  determines  if  all  fuel  inlets  have  been 
scheduled  for  refueling  for  this  unit.  If  not,  control  goes  to  block  23; 
otherwise,  the  refuel  pointer  is  incremented,  control  goes  to  block  11,  and 
a  new  mission  unit  is  considered. 

(12)  Block  11.  If  the  new  unit  has  landed  at  the  FRRA,  control 
goes  to  block  15.  If  the  unit  has  not  landed,  the  fuel  consumed  while  it 
loitered  is  calculated  and  subtracted  from  the  mission  unit's  status  record. 
Control  goes  to  block  12. 

(13)  Block  12.  Refueling  time  per  inlet  is  calculated  for  this  unit. 
A  constant  50-gallons-per-minute  intake  rate  is  assumed  for  all  aircraft 
inlets.  A  maneuver  time  is  also  included. 

(14)  Block  13.  A  check  determines  if  the  new  unit  requires  rearming. 
If  it  does  not,  control  passes  to  block  15.  If  it  does,  routine  RATIM  is 
called  to  determine  the  earliest  time  a  rearming  capability  will  be  avail¬ 
able.  If  a  rearming  capability  will  be  unavailable  when  this  segment  finishes 
refueling,  control  goes  to  block  14. 

(15)  Block  14.  If  refueling  of  the  aircraft  is  delayed  until  a 
previous  unit  releases  a  rearming  capability,  the  necessary  delay  is  scheduled 
with  IOPR  equal  46  and  control  goes  to  block  21. 

(16)  Block  15.  If  refueling  can  be  scheduled  immediately,  a  check 
is  made  to  ensure  that  there  is  sufficient  fuel  at  the  FRRA  to  refuel  this 
flight  segment.  If  sufficient  fuel  is  unavailable,  a  15-minute  delay  is 
scheduled  with  IOPR  *  46.  The  15-minute  delay  allows  the  FRRA  unit  to  be 
resupplied  with  fuel.  If,  at  the  end  of  the  15-minute  delay,  fuel  is  still 
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unavailable,  another  15-minute  delay  will  be  scheduled.  Delays  will  be 
scheduled  until  fuel  becomes  available  at  the  FRRA.  Routine  REFUEL  determines 
if  fuel  is  available  at  the  FRRA.  If  fuel  is  unavailable,  control  goes  to 
block  21  after  the  delay  is  scheduled. 

(17)  Block  16.  If  sufficient  fuel  is  available  for  this  flight 
segment,  a  check  determines  whether  the  unit  has  landed.  If  it  has  not, 
the  appropriate  parameters  are  adjusted  on  its  unit  status  record  to 
simulate  landing. 

(18)  Block  17.  The  refueling  event  is  scheduled. 

(19)  Block  18.  If  there  are  refueling  nozzles  available  for  use, 
a  search  is  made  for  another  unit  to  refuel.  If  all  refuel  nozzles  were  in 
use,  control  passes  to  block  21. 

(20)  Block  19.  If  nozzles  are  available,  a  check  is  made  to  determine 
if  there  are  units  in  the  refuel  queue.  If  so,  control  passes  to  block  23; 
otherwise,  control  goes  to  block  20. 

(21)  Block  20.  If  the  current  mission  unit  has  been  loitering, 
control  goes  to  block  11;  otherwise,  the  data  file  information  is  stored 
and  control  returns  to  the  calling  routine. 

(22)  Block  21.  NTIME  is  set  equal  to  TCLOCK  and  control  goes  to 
block  23. 

(23)  Block  22.  A  mission  unit  entering  at  this  point  (IOPR  -  47) 
has  made  previous  attempts  to  rearm,  facilities  were  not  available,  and 

is  again  attempting  to  rearm.  As  in  blocks  1  and  9,  the  necessary  informa¬ 
tion  is  read  from  the  data  files. 

(24)  Block  23.  If  no  rearming  points  are  available  control  goes  to 
block  28. 

(25)  Block  24.  If  rearm  points  are  available  and  there  are 
aircraft  that  need  rearming  control  goes  to  block  25.  If  no  aircraft  require 
rearming,  a  search  is  initiated  for  another  unit  to  rearm  by  incrementing 

the  rearm  pointer  by  one. 

(26)  Block  25.  If  the  rearming  queue  is  empty,  control  goes  to 
block  27;  otherwise,  a  check  is  made  to  determine  if  the  new  unit  has 
aircraft  to  rearm.  If  not,  control  goes  to  block  27. 

(27)  Block  26.  If  the  current  unit  has  aircraft  that  require 
rearming,  routine  REFUEL  is  called.  If  rearming  is  complete,  control  goes 
to  block  27;  otherwise,  control  goes  to  block  23. 

(28)  Block  27.  The  mission  unit's  status  record  is  put  on  data 

file  1. 
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(29)  Block  28.  The  FRRA  unit's  status  record  is  put  on  data  file  1 
and  the  work  area  is  put  on  data  file  24.  Control  returns  to  the  calling 
routine. 

(30)  Block  29.  A  mission  unit  entering  at  this  point  (10PR  =  44) 
has  partially  completed  rearming.  The  data  file  information  is  read  as  in 
blocks  1,  9,  and  22. 

(31)  Block  30.  The  number  of  rearming  points  available  is 
recalculated  to  allow  for  losses  from  attrition  or  increases  through  resupply. 

(32)  Block  31.  The  number  of  rearming  points  not  in  use  is  increased 
by  the  number  of  aircraft  that  have  completed  rearming.  Rearming  points  are 
also  modified  to  consider  changes  calculated  in  block  30. 

(33)  Block  32.  The  number  of  remaining  aircraft  to  be  rearmed  is 
reduced  by  the  number  of  aircraft  that  have  completed  rearming. 

(34)  Block  33.  If  all  aircraft  in  this  unit  have  not  completed 
rearming,  control  goes  back  to  block  24.  If  all  aircraft  have  rearmed,  the 
munitions  are  transferred  from  the  FRRA  unit's  status  record  to  the  mission 
unit's  status  record.  JFLY  is  set  equal  to  two. 

(35)  Block  34.  If  both  refueling  and  rearming  events  are  incomplete 
for  this  flight  unit,  the  mission  unit's  status  record  is  put  on  data  file 

1,  and  control  goes  to  block  24. 

(36)  Block  35.  If  both  refueling  and  rearming  events  of  this 
flight  unit  are  complete,  the  event  to  fly  the  unit  to  its  next  objective 
is  scheduled. 

(37)  Block  36.  If  JFLY  equal  2,  control  goes  to  block  24.  If 
JFLY  equal  1,  control  goes  to  block  8. 

17.  ROUTINE  REFUEL: 

a.  Purpose.  This  routine,  called  by  RRFLD,  adjusts  the  supply  point 
queue  parameters  necessary  for  refueling  and  rearming. 

b.  Input  Variables: 

(1)  Standard  Common  Block  Area.  FRRA. 

(2)  Other  Variables: 


Name 

Source 

Contents 

NFUEL 

Call 

Refueling  capability: 

NFUEL  ■  0,  aircraft  cannot  be  refueled  at 
this  time. 

NFUEL  *  1,  aircraft  will  be  refueled. 
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c.  Output  Variables: 


(1)  Standard  common  block  variables. 

(2)  Other  Variables: 


Name  Destination  Contents 

IDT  Call  Time  increment  that  will  be  added  to  the  current 

time  to  determine  when  the  event  being  scheduled 
will  occur. 

ACBP  Call  Number  of  aircraft  in  this  segment, 

d.  Logical  Flow  (FigureIV-15-B-15) : 

(1)  Block  1.  This  block  checks  the  value  of  the  time  increment 
(IDT)  and  control  is  transferred  to  block  1A  (refueling)  if  it  is  less  than 
zero;  otherwise,  control  is  transferred  to  block  9  (rearming). 

(2)  Block  1A.  The  supply  point  queue  parameters  necessary  for 
refueling  are  adjusted.  If  NFUEL  =  1  sufficient  fuel  is  available;  other¬ 
wise,  control  flows  to  block  2. 

(3)  Block  2.  The  fuel  needed  by  this  flight  segment  is  calculated 
as  the  product  of  the  number  of  inlets  being  fueled  in  this  segment  times 
the  number  of  gallons  required  by  each  inlet. 

(4)  Block  3.  If  the  supply  point  has  sufficient  fuel  available  to 
refuel  this  flight  segment,  control  flows  to  block  5;  otherwise,  block  4  is 
executed. 


(5)  Block  4.  When  fuel  at  the  supply  point  is  insufficient,  the 
flight  is  put  in  a  holding  area  for  15  minutes.  NFUEL  is  set  equal  to  0, 

IOPR  is  set  equal  to  46,  and  IDT  is  set  equal  to  1500.  Control  returns  to 
RREXEC.  After  15  minutes  another  attempt  will  be  made  to  refuel  this  flight 
segment.  If  resupply  of  fuel  by  the  Combat  Service  Support  Model  has  occurred, 
the  refueling  will  be  accomplished  on  the  next  attempt. 


(6)  Block  5  and  6.  If  sufficient  fuel  is  available  to  refuel  the 
flight  segment,  a  check  is  made  to  determine  if  refuel  nozzles  are  avail¬ 
able.  If  they  are  not,  NFUEL  is  set  equal  to  zero  and  control  returns  to 
RREXEC;  otherwise,  control  flows  to  block  7. 


(7)  Block  7.  Refueling  of  the  flight  segment  is  possible.  Refueling 
capacity  is  reduced  by  the  number  of  inlets  being  refueled;  the  number  of 
inlets  to  be  refueled  is  reduced  by  the  number  of  inlets  being  refueled. 

ACBP  is  set  equal  to  the  number  of  inlets  being  refueled. 

(8)  Block  8.  The  time  that  the  refueling  of  this  flight  segment 
will  be  completed  is  put  in  IDT,  IOPR  is  set  equal  to  43,  and  NFUEL  is  set 
to  1.  Control  returns  to  RREXEC. 
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Figure  IV-15-B-15.  Routine  REFUEL  (Continued  on  Next  Page) 
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Figure  IV-15-B-15.  Routine  REFUEL  (Concluded) 
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(9)  Block.  9.  The  supply  point  queue  parameters  necessary  for 
rearming  are  adjusted  and  the  number  of  aircraft  to  be  rearmed  is  calculated 
as  the  minimum  of  the  available  rearming  capability  and  the  number  of 
aircraft  that  are  ready  to  be  rearmed. 

(10)  Block  10.  If  the  amount  of  ammunition, at  the  supply  point 

is  insufficient  to  rearm  this  aircraft  flight  segment,  a  15-minute  delay  in 
rearming  is  scheduled  by  scheduling  an  airmobile  event  with  an  operation 
code  of  47.  The  flight  segment  is  held  in  the  queue  until  it  is  time  to 
attempt  rearming  again.  NAMO  is  set  equal  to  zero. 

(11)  Block  11.  If  the  amount  of  ammunition  at  the  FRRA  meets  the 
needs  for  this  flight  segment,  NAMO  is  set  equal  to  one.  A  test  is  made 
to  determine  if  the  rearming  point  has  a  rearming  capability  available.  If 
it  does  not,  NAMO  and  NFUEL  are  set  equal  to  zero  and  control  returns  to 
routine  RRFLD. 

(12)  Block  12.  If  a  rearming  capability  is  available  at  the  FRRA, 
rearming  will  be  performed.  The  number  of  aircraft  that  will  be  rearmed 

in  this  flight  segment  (ACBP)  is  the  lesser  of  the  number  of  rearming  points 
available  for  rearming  (RAC)  and  the  number  of  aircraft  that  are  ready  for 
rearming  (READY).  The  parameter  with  the  minimum  value  is  set  equal  to  zero. 
ACBP  is  subtracted  from  the  larger  quantity  and  from  the  number  of  aircraft 
that  require  rearming. 

(13)  Block  13.  The  time  that  this  flight  segment  will  complete 
rearming  is  calculated  as  the  rearming  time  to  rearm  one  aircraft  plus  a 
rearming  maneuver  time  plus  the  current  game  time.  This  completion  time 
and  the  number  of  aircraft  in  the  flight  fragment  are  stored  for  use  in 
routine  RATIM. 

(14)  Block  14.  The  rearming  event  is  scheduled  with  an  IOPR  code 

for  44. 

18.  ROUTINE  RATIM: 

a.  Purpose.  The  refueling/rearming  portion  of  the  Airmobiel  Model  is 
designed  so  that  an  aircraft  will  not  land  at  an  FRRA  if  a  rearming  capability 
will  not  be  available  at  the  time  the  unit's  first  flight  segment  completes 
refueling.  Instead,  the  flight  is  diverted  to  a  holding  area  until  rearming 
capability  is  available  at  the  FRRA.  This  routine,  called  by  RRFLD,  calculates 
the  time  rearming  capability  will  become  available  to  this  unit. 

b.  Input  Variables: 

(1)  Common  Block  Areas.  FRRA,  LGTPER. 

(2)  Other  Variables: 

Name  Source  Contents 

RRAP  Call  An  index  equal  to  RAP  that  points  to  the  mission 

unit  in  the  work  array  that  is  requesting  rearming. 
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Name 


Source 


Con Cents 


IPT  Call  An  index  which  points  to  the  previous  mission 

unit . 

c.  Output  Variables: 

Name  Destination  Contents 

KTMA  Call  Earliest  time  this  unit  can  start  refueling 

(this  time  is  added  to  TCLOCK) . 

d.  Logical  Flow  (Figure  IV-15-B-16) : 

(1)  Block  1.  When  this  routine  is  entered,  the  number  of  rearming 
points  that  are  available  is  reduced  by  the  number  of  points  that  have 
been  attriced. 

(2)  Block  2.  The  number  of  rearming  points  required  by  the  flight 
unit  under  consideration  is  determined. 

(3)  Block  3.  The  RACAT  array  is  examined  to  determine  if  any  flight 
segments  are  being  rearmed.  If  not,  control  passes  to  block  7. 

(4)  Block  4.  If  the  RACAT  array  contains  flight  segments,  the 
segment  that  will  be  rearmed  next  is  examined. 

(5)  Block  5.  The  number  of  reaming  points  that  will  be  released 
after  this  segment  is  reamed  is  added  to  the  available  rearming  capability. 

(6)  Block  6.  A  new  time  is  calculated  for  the  completion  of 
rearming  for  the  next  flight  segment  of  the  previous  unit.  If  the  previous 
flight  unit  has  all  reaming  scheduled,  control  goes  to  block  7;  otherwise, 
control  returns  to  block  3. 

(7)  Block  7.  The  time  counter,  KTMA,  will  contain  the  time  reaming 
capability  will  be  available. 

19.  ROUTINE  RRTURN: 

a.  Purpose.  This  routine  updates  parameters  and  returns  control  of 
the  mission  unit  to  the  model  requesting  that  it  be  resupplied. 

b.  Input  Variables: 

(1)  Standard  Common  Areas.  UMAIN,  UCOOP,  and  FRRA. 

(2)  Other  Variable: 

Name  Source  Contents 


MUID  TWO  IUID  of  FRRA  unit  for  mission  unit. 


IV-15-B-68 


CALCULATE 
REARKING  POINTS 
LOST 


Figure  IV-15-B-16.  Routine  RATIM 
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c.  Output  Variables: 


Maine 


(1)  FRRA  Common  Block  Variable.  IOPR. 

(2)  Other  Variable: 

Destination  Contents 


ONE 


IFNT  (56,1) 

d.  Logical  Flow  (Figure  IV-15-B-17) : 


Cycle  flag  indicating  whether  another  airmobile 
event  is  to  follow  immediately. 


(1)  Block  1.  When  this  routine  is  called,  the  status  record  of 
the  mission  unit  which  completed  refueling/rearming  operations  is  read  into 
UMAIN. 


(2)  Block  2.  The  mission  unit  has  reached  its  new  objective  and  is 
ready  for  the  next  airmobile  event.  The  unit  assumes  the  coordinates  of 
its  new  location. 

(3)  Block  3.  Fuel  consumed  by  the  mission  unit  in  flying  from 
the  FRRA  to  the  new  objective  is  calculated  and  subtracted  from  the  mission 
unit's  status  record. 

(4)  Block  4.  The  mission  unit's  status  record  is  put  back  on  data 
file  1  and  the  FRRA  unit's  status  record  is  read.  The  record  number  on  data 
file  24  that  gives  data  file  12  information  for  this  unit  is  taken  from  the 
FRRA  unit's  status  record. 

(5)  Block  5.  The  FRRA  work  area  array  is  obtained  from  data  file  24. 

(6)  Block  6.  The  next  Airmobile  IOPR  is  obtained  from  word  35 

of  data  file  12  array,  IFNT  (56,1)  is  set  equal  to  one,  and  control  returns 
to  the  calling  routine  that  processes  the  next  airmobile  event. 

20.  ROUTINE  RLEAS : 

a.  Purpose.  Routine  RLEAS  is  the  executive  driver  for  the  group  of 
routines  associated  with  the  release  of  escort  and  transport  aircraft 
terminating  an  airmobile  lift.  Routine  RLEAS  is  activated  by  a  DSL  release 
transport  order. 

b.  Input  Variables: 

Name  Source  Contents 

IOPER  TWO  Program  operation  code,  IDUM  (94). 

c.  Output  Variables.  None. 

d.  Logical  Flow  (Figure  IV-15-B-18) : 
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Figure  IV-15-B-18.  Routine  RLEAS 
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(1)  Block  1.  Determine  the  operation  code  from  IOPER  to  direct 
RLEAS  to  call  the  proper  routine. 

(2)  Blocks  L100,  L200,  L300,  and  L400.  Routines  within  the  RLEAS 
segment  are  called. 

21.  ROUTINE  RLEAS1 : 

a.  Purpose.  Routine  RLEAS1  first  determines  if  any  part  of  the  return 
flight,  to  the  airbase,  is  over  enemy  airspace.  If  so,  an  air  mission  unit 
is  created.  Both  escort  and  transport  aircraft  with  related  resources  are 
transferred  from  the  unit  at  the  landing  zone  to  the  mission  unit.  An  event  is 
scheduled  for  in-flight  attrition.  If  penetration  of  enemy  airspace  is  not 
required,  the  aircraft  are  flown  back  to  their  respective  airbases. 

b.  Input  Variables: 


(1) 

Standard  Common 

Block  Variables. 

(2) 

Other  Variables 

: 

Name 

Source 

Contents 

IUIDTP 

TWO 

Unit  that  was  transported. 

IDMSTR 

TWO 

Newly  created  mission  unit. 

MIXTAB 

DF7 

Mission  resource  data. 

ACAVL (72) 

DF26 

Aircraft  item  code  data. 

FLTSPD(36) 

DF26 

Aircraft  flight  speeds. 

CONSMP (10) 

DF14 

Aircraft  fuel  consumption  rates 

c.  Output  Variables: 

(1)  Standard  Common  Block  Variables. 

(2)  Other  Variables: 


Name 

Source 

Contents 

IFLG 

TWO 

Penetration  flag;  0  -  no,  1  -  yes. 

FUEL 

TWO 

Aircraft  fuel  to  be  consumed  during  next  flight 
segment. 

TRATE 

TWO 

Transport  fuel  consumption  rate. 

ERATE 

TWO 

Escort  fuel  consumption  rate. 
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d.  Logical  Flow  (Figure  IV-15-B-19): 

(1)  Block  1.  The  unit  status  record  of  the  unit  that  was  transported 
is  obtained  from  data  file  1. 

(2)  Block  2.  The  flight  speeds  of  the  transport  and  escort  aircraft 
are  determined. 

(3)  Block  3.  The  fuel  consumption  rates  for  transport  and  escort 
aircraft  are  determined. 

(4)  Blocks  4  and  5.  Routine  PENRAT  determines  if  the  next  flight 
segment  will  fly  over  enemy  airspace. 

(5)  Block  6.  If  escort  aircraft  accompaned  the  airlift,  control 
goes  to  block  L100. 

(6)  Blocks  7,  8,  and  L100.  If  escort  and  transport  aircraft 
originate  at  the  same  airbase,  control  transfers  to  Block  L100.  Only  one 
mission  unit  is  created  and  the  aircraft  fly  as  a  single  unit.  If  they 
originated  at  separate  airbases,  two  separate  mission  units  must  be  created, 
and  aircraft  fly  to  separate  airbases. 

(7)  Block  L175.  Create  an  air  mission  unit. 

(8)  Block  9.  If  escort  aircraft  did  not  accompany  the  airlift, 
control  transfers  to  block  L340. 

(9)  Block  10.  If  an  escort  mission  unit  has  been  created  and 
loaded,  control  transfers  to  block  L340. 

(10)  Block  13  -  Transfer  the  escort  aircraft  and  related  resources 
and  equipment  from  the  transported  unit  to  the  mission  unit. 

(11)  Block  12.  If  another  air  mission  unit  is  needed,  control 
goes  to  block  L175. 

(12)  Block  L340.  Transfer  the  transport  aircraft  and  related 
resources  and  equipment  from  the  transported  unit  to  the  mission  unit. 

(13)  Block  13.  Set  the  coordinates  of  the  mission  unit  to  those 
of  the  transported  unit  at  the  landing  zone. 

(14)  Blocks  14,  15,  and  16.  Determine  if  penetration  will  occur. 

If  so,  set  the  objective  coordinates  of  the  mission  unit  to  those  of  the 
safe  point,  and  set  an  event  to  schedule  the  in-flight  attrition  segment. 

(15)  Block  17.  Determine  if  one  or  two  mission  units  were  created. 

(16)  Block  18.  Set  the  objective  coordinates  of  the  mission  unit(s) 
to  those  of  the  airbase(s). 
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Figure  IV-15-B-19.  Routine  RLEAS1  (Concluded) 
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(17)  Block  19.  Compute  the  arrival  time  at  the  airbase(s). 

(18)  Block  20.  Compute  the  fuel  consumed  by  the  mission  unit(s) 
on  the  return  flight  segment. 

(19)  Block  21.  Schedule  the  arrival  of  the  aircraft  at  the 
airbase(s) . 

22.  ROUTINE  RLEAS2 : 


a.  Purpose.  Routine  RLEAS2  is  called  by  routine  RLEAS  following  an 
in-flight  attrition  assessment  of  the  mission  unit  on  its  return  flight  to 
the  airbase.  Routine  RLEAS2  determines  the  airbase (s)  from  which  the  aircraft 
originated  and  schedules  their  return. 

b.  Input  Variables: 

(1)  Standard  Common  Block  Variables. 


(2)  Other  Variables 

• 

Name 

Source 

Contents 

MSNUNT 

TWO 

Escort  mission  unit. 

FUEL 

TWO 

Fuel  consumed  on  last  flight  segment 

TRATE 

TWO 

Transport  fuel  consumption  rate. 

ERATE 

TWO 

Escort  fuel  consumption  rate. 

MIXTAB(12) 

DF7 

Mission  resource  data. 

c. 

Output 

Variables : 

(1)  Standard  Common  Block. 

(2)  Other  Variables: 

Name  Source 


Contents 


FUEL  TWO  Fuel  to  be  consumed  on  the  next  flight  segment. 

IDTRaN  TWO  Transport  mission  unit, 

d.  Logical  Flow  (Figure  IV-15-B-20) : 

(1)  Block  1.  Get  the  unit  status  record  of  the  air  mission  unit 
from  data  file  1. 

(2)  Block  2.  Compute  the  time  required  for  the  transports  to 
return  to  the  airbase. 
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Figure  IV-15-B-20. 


Routine  RLEAS2  (Concluded) 
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(3)  Block  3.  Determine  if  both  transport  and  escort  aircraft 
originate  at  the  same  airbase. 

(4)  Block  L100.  Build  an  air  mission  unit  for  the  return  of  the 
transport  aircraft. 

(5)  Block  4.  Determine  if  there  is  sufficient  fuel  for  the 
transport  aircraft's  return  flight. 

(6)  Block  5.  Schedule  an  event  for  the  arrival  of  the  transport 
aircraft  at  the  airbase. 

(7)  Block  L200.  Schedule  an  event  for  the  transport  mission  unit 
to  refuel  at  the  nearest  refueling  facility. 

(8)  Block  6.  Compute  the  time  required  for  the  escorts  to  return 
to  the  airbase. 

(9)  Blocks  L300  and  7.  If  there  is  sufficient  fuel  for  the  escort 
aircraft's  return  flight,  an  event  is  scheduled  for  the  arrival  of  the 
escort  aircraft  at  the  airbase.  If  not,  control  goes  to  block  L400. 

(10)  Block  L400.  An  event  is  scheduled  for  the  escort  mission 
unit  to  refuel  at  the  nearest  refueling  facility. 

(11)  Blocks  L525  and  L550.  Replace  the  unit  status  record(s)  of 
the  mission  unit(s)  on  data  file  1. 

23.  ROUTINE  RLEAS3: 

a.  Purpose.  Routine  RLEAS3  is  called  by  routine  RLEAS  when  the  aircraft 
have  arrived  at  the  airbase  to  determine  landing  times  and  maintenance 
availability  times  associated  with  aircraft  damage  and  to  schedule  an  event 
for  the  restoration  of  the  aircraft  into  the  airbase. 


b.  Input  Variables: 

(1)  Standard  Common  Block  Variables. 

(2)  Other  Variables: 


Name 

Source 

Contents 

PENFLG 

TWO 

Penetration  flag;  0  =  no , 

1  *  yes. 

IUIDAB 

TWO 

Airbase  unit. 

MSNUNT 

TWO 

Air  mission  unit. 

FUEL 

TWO 

Fuel  consumed  on  the  last 

flight  segment 

ACAVL (72) 

DF26 

Aircraft  item  code  data. 
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Name 


Contents 


Source 


LANDTM(36) 

DF26 

AVLTM1 (36) 

DF26 

AVLTM2 (36) 

DF26 

Aircraft  landing  times. 

Escort  availability  times. 
Transport  availability  times. 


Name 


AMOUNT 


c.  Output  Variables: 

(1)  Standard  Common  Block. 

(2)  Other  Variables: 

Source 


Contents 


TWO 


Amound  of  aircraft  to  be  restored. 


d.  Logical  Flow  (Figure  IV-15-B-21) : 

(1)  Block  1.  Bring  in  the  unit  status  record  of  the  air  mission 
unit  from  data  file  1. 


(2)  Block  2.  Bring  in  the  unit  status  record  of  the  airbase  unit 
from  data  file  1. 


(3)  Block  3.  Determine  if  the  aircraft  in  the  mission  unit  are 
escort  or  transport. 

(4)  Block  4.  Transfer  the  aircraft  fuel  and  personnel  from  the 
air  mission  unit  to  the  airbase  unit. 

(5)  Blocks  5,  6,  and  L310.  Determine  whether  the  aircraft  are 
escorts  or  transports. 

(6)  Block  L4Q.  Transfer  escort  aircraft  munitions  from  the  air 
mission  unit  to  the  airbase  unit. 

(7)  Blocks  7  and  8.  Determine  the  landing  time  for  appropriate 
escort  or  transport  aircraft  as  a  function  of  speed  and  prevailing  weather 
conditions . 


(8)  Block  9.  Obtain  the  availability  times  of  damaged  aircraft  in 
repair  from  data  file  26. 

(9)  Block  L325.  Determine  if  the  return  flight  segment  penetrated 
enemy  airspace.  If  so,  control  passes  to  block  12. 

(10)  Blocks  10  and  11.  If  any  aircraft  sustained  a  B-kill,  an 
event  is  scheduled,  as  a  function  of  the  availability  time  for  a  B-kill, 
to  restore  the  aircraft  at  the  airbase.  Increment  the  activity  counter  to 
report  aircraft  unavailable. 
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Figure  IV-15-B-21.  Routine  RLEAS3  (Concluded) 
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(11)  Block  12.  Determine  if  any  aircraft  sustained  a  C-i.ill.  If 
not,  control  passes  to  block  14. 

(12)  Block  13.  If  so,  an  event  is  scheduled,  as  a  function  of  the 
availability  time  for  a  C-kill,  to  restore  the  aircraft  at  the  airbase. 
Increment  the  activity  counter  to  report  aircraft  unavailable. 

(13)  Blocks  14  and  15.  If  any  aircraft  sustained  a  D-kill,  schedule 
an  event,  as  a  function  of  the  availability  time  for  a  D-kill,  to  restore 
the  aircraft  at  the  airbase.  Increment  the  activity  counter  to  report  air¬ 
craft  unavailable.  If  not,  control  goes  to  block  16. 

(14)  Blocks  16  and  17.  If  there  are  undamaged  aircraft,  schedule 
an  event,  as  a  function  of  landing  time,  to  restore  the  aircraft  at  the 
airbase.  Increment  the  activity  counter  to  report  aircraft  unavailable. 

(15)  Block  L500.  Clear  the  status  record  of  the  mission  unit  and 
return  it  to  data  file  1. 

24.  ROUTINE  RLEAS4: 

a.  Purpose.  Routine  RLEAS4,  called  by  routine  RLEAS ,  restores  damaged 
and  undamaged  aircraft  to  the  airbase  at  the  completion  of  the  delay  imposed 
by  landing  and  damage  repair  times. 

b.  Input  Variables: 

(1)  Standard  Common  Block  Variables. 

(2)  Other  Variables: 


Name 

Source 

Contents 

IUIDAB 

TWO 

Airbase  identification. 

IACEOH 

TWO 

Aircraft  item  code. 

AMOUNT 

TWO 

Number  of  aircraft  damaged. 

c. 

Output  Variables. 

Standard  Common  Block  Variables 

d. 

Logical  Flow  (Figure  IV-15-B-22): 

(1)  Block  1.  Bring  in  the  status  record  of  the  airbase  unit  from 
data  file  1. 

(2)  Block  2.  Restore  the  aircraft  to  availability  status  at  the 

airbase. 

(3)  Block  3.  Decrement  the  activity  counter  by  the  number  of 
aircraft  being  restored  into  the  airbase. 
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(4)  Block  4.  Replace  the  airbase  unit  status  record  on  data  file  1. 
25.  ROUTINE  PENRAT. 

a.  Purpose.  This  routine  establishes  X  and  Y  coordinates  at  the  location 
the  flight  path  enters  hostile  airspace.  If  a  given  point  on  the  flight  path 
is  within  hostile  airspace,  a  flag  is  set  to  indicate  that  penetration  of 
hostile  airspace  will  occur.  By  considering  aircraft  type  and  weather 
visibility,  the  time  to  fly  from  the  pickup  point  to  a  safe  point  is  calcu¬ 
lated.  PENRAT  is  called  by  ACCPT1,  ACCPT2 ,  and  RLE AS 1. 

b.  Input  Variables: 


(1) 

Standard  Common  Block  Variables. 

(2) 

Other  Variables 

>'• 

Name 

Source 

Contents 

IUIDTP 

TWO 

IUID  of  unit  being  transported  by  air. 

FUNIT 

ZONDAT 

IUIDs  of  enemy  front-line  battalions. 

IDEP 

DF1 

Depth  of  forwardmost  enemy  unit. 

FLTSPD 

DF26 

Flight  airspeed. 

SLOPE 

ONE 

Slope  of  the  battlefield  (for  line  joining  centers 
of  mass  of  Red  and  Blue  units). 

c. 

Output  Variables: 

Name 

Destination 

Contents 

IFLG 

Call 

Penetration  flag:  0  *  pickup  point  is  not 
inside  hostile  airspace;  1  =  pickup  point  is 
inside  hostile  airspace. 

AXFEBA 

Call 

X  coordinate  of  safe  point. 

AYFEBA 

Call 

Y  coordinate  of  safe  point. 

ITIME 

Call 

Time  to  fly  from  pickup  point  to  safe  point. 

d.  Logical  Flow  (Figure  IV-15-B-23): 


(1)  Block  1.  The  front-line  enemy  maneuver  battalions  are 
identified  by  the  array  FUNIT  in  common  ZONDAT.  The  X  intercept  of  each 
unit  is  calculated. 

(2)  Block  L75.  The  forwardmost  enemy  unit  is  determined  by 
ranking  X  intercepts  according  to  force. 
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(3)  Block  2.  The  safe  distance,  composed  of  one  half  the  depth 
of  the  forwardmost  unit  plus  a  local  constant  (currently  6000  meters) ,  is 
translated  into  its  X  component. 

(4)  Block  3.  The  X  intercept  (PINCEP)  is  calculated  for  a  line 
parallel  to  the  FEBA  and  passing  through  the  designated  point  on  the  flight 
path  (pickup  point). 

(5)  Block  4.  Depending  on  whether  the  flight  is  Red  force  of 

Blue  force,  the  X  component  of  the  safe  distance  is  applied  to  establish  the 
X  intercept  of  the  safe  line.  Accordingly,  if  the  designated  point  on  the 
flight  path  (pickup  point)  is  within  hostile  airspace,  the  penetration 
flag  remains  set  to  one;  otherwise,  it  is  set  to  zero. 

(6)  Block  L175.  The  distance  from  the  designated  pickup  point 
perpendicular  to  the  safe  line  is  calculated  from  the  X  component  of  this 
distance  and  the  angle  represented  by  the  slope  of  the  battlefield. 

(7)  Block  5.  Cruise  speed  and  flight  time  are  developed.  Depending 
on  the  calling  routine,  flight  speed  is  obtained  from  either  the  unit  status 
file  or  from  data  file  26  based  on  weather  and  aircraft  type. 

26.  ROUTINE  SETTYP : 


a.  Purpose.  This  routine  sets  a  designated  element  within  a  character 
array  to  a  designated  character  value.  The  character  array  is  composed  of 

a  series  of  integer  words,  each  containing  four  characters  (left  justified). 

b.  Input  Variables: 

Name  Source  Contents 

IEOH  Call  Number  of  the  character  element  to  be  set. 

(Normally  an  equipment  item  code). 

LETR  Call  A  word  containing  the  character  to  be  set  into 

EOHTYP.  The  character  is  left  justified. 

c.  Output  Variables: 

Name  Destination  Contents 

EOHTYP (50)  Call  Array  containing  four  characters  per  word,  left 

justified. 

d.  Logical  Flow  (Figure  IV-15-B-24) : 

(1)  Block  1.  The  word  within  EOHTYP  that  contains  the  character 
to  be  set  is  calculated  by: 

IWRD  -  (IEOH  -  1)  /  4  +  1  (IV-15-B-1) 
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(2)  Block  2.  The  character  within  that  word  is  calculated  by: 

IEOH  -  (IWRD  -  1)  *  4  (IV-15-B-2/ 

(3)  Block  3.  Routine  MVCHAR  is  called  to  move  the  first  character 
of  LETR  into  the  appropriate  character  of  EOHTYP. 

27.  ROUTINE  MI SUNT: 

a.  Purpose.  This  routine  identifies  an  available  mission  unit  to  be 
used  for  an  airmobile  operation.  If  no  such  unit  is  available,  a  new  mission 
unit  is  created. 


b.  Input  Variables: 

(1)  Standard  Common  Area.  UNTLOC. 

(2)  Other  Variables: 


Name 

Source 

Contents 

IFORCE 

Call 

Flag 
unit : 

indicating  the  force  requiring  a  mission 

1  *  Blue,  2  =  Red 

c. 

Output  Variables: 

Name 

Destination 

Contents 

IUID 

Call 

Unit 

identification  number  of  the  mission  unit. 

UID(2) 

Call 

Alphanumeric  identification  of  the  mission  unit. 

d.  Logical  Flow  (Figure  IV-15-B-25) : 

(1)  Block  1.  The  content  of  UID  is  set  to  an  initial  value  of 
BBBB0001  (Blue)  or  RRRR0001  (Red). 

(2)  Block  L10.  Function  IUIDF  is  called  to  return  the  IUID  of  the 
unit  identified  by  UID.  If  the  unit  has  not  previously  been  defined,  a 
value  of  zero  is  returned. 

(3)  Block  2.  If  the  unit  has  not  been  defined,  control  goes  to 
block  L100;  otherwise,  control  goes  to  block  3. 

(4)  Block  3.  If  the  unit's  location  is  not  zero,  it  is  being  used 
and  control  goes  to  block  L50  to  select  another  unit. 

(5)  Block  L50.  The  counter  in  the  lower  four  characters  of  UID  is 
incremented  and  control  loops  to  block  L10. 
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(6)  Block  L100.  If  no  previously  defined  mission  unit  is  currently 
available,  routine  ADDUNT  is  called  to  add  another  unit  and  assign  it  the 
UID  constructed  in  blocks  L10  and  L50. 

(7)  Block  4.  The  IUID  is  returned  from  either  IUIDF  or  ADDUNT. 
Control  returns  to  the  calling  routine. 

28.  ROUTINE  MORS: 

a.  Purpose.  This  routine  is  the  driver  program  for  overlay  17,  segment 
5.  It  calls  routine  MES  or  routine  SIS. 

b.  Input  Variables: 

Name  Source  Contents 

FILE12(1)  TWO  Operation  code. 

c.  Output  Variables.  None. 

d.  Logical  Flow.  This  routine  extracts  the  rightmost  digit  of  FILE12(1) 
as  the  operation  code  and  calls  routine  SIS  if  this  operation  code  value  is 
equal  to  two;  otherwise,  routine  MES  is  called. 

29 .  ROUTINE  CIRCLE : 

a.  Purpose.  This  routine  returns  the  central  angle  subtended  by  that 
portion  of  the  circumference  of  a  given  circle  (lying  in  the  X,Y  plane) 
that  is  contained  within  the  radius  of  a  given  sphere.  The  elevations  of 
circle  and  sphere  centers  are  specified  and  can  differ. 

b.  Input  Variables: 

Name  Source  Contents 


XI 

Call 

X  coordinate  of  center 

of 

circle. 

Y1 

Call 

Y  coordinate  of  center 

of 

circle. 

Z1 

Call 

Z  coordinate  of  center 

of 

circle . 

R1 

Call 

Radius  of  circle. 

X2 

Call 

X  coordinate  of  center 

of 

sphere. 

Y2 

Call 

Y  coordinate  of  center 

of 

sphere. 

22 

Call 

Z  coordinate  of  center 

of 

sphere. 

R2 

Call 

Radius  of  sphere. 
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c.  Output  Variables: 


Name 

Destination 

Contents 

CIRCLE 

Call 

Central  angle 
portion  of  its 
sphere. 

subtended  in  circle  by  that 
circumference  contained  in 

d. 

Logical  Flow  (Figure 

IV-15-B-26) : 

(1)  Block  1.  The  slant  and  horizontal  distance  between  centers 
of  circle  and  sphere,  and  the  radius  of  the  sphere  as  intersected  by  the 
plane  of  the  circle,  are  calculated  from  the  coordinates. 


(2)  Blocks  2  and  3.  If  the  horizontal  distance  between  centers  of 
circle  and  sphere  equals  or  exceeds  the  sum  of  the  radius  of  the  circle  plus 
the  radius  of  the  sphere  as  intersected  by  the  plane  of  the  circle,  no 
overlap  of  the  circle  by  the  sphere  is  possible,  and  the  desired  output 
angle  is  set  to  zero. 

(3)  Blocks  4  and  5.  If  the  horizontal  distance  between  centers  of 
circle  and  sphere  is  less  than  or  equal  to  the  radius  of  the  sphere  as  inter 
sected  by  the  plane  of  the  circle  less  the  radius  of  the  circle,  the  circle 
must  be  totally  contained  by  the  sphere,  and  the  desired  output  angle  is  set 
to  2  T  . 

(4)  Block  6.  The  central  angle  subtended  by  that  portion  of  the 
circumference  of  the  circle  which  is  within  the  sphere  is  computed  by  the 
half-angle  formula. 

30.  ROUTINE  GASRCH: 

a.  Purpose.  This  routine  generates  a  list  of  enemy  units  that  are 
located  within  the  specified  radius  of  a  given  point.  Only  air  defense 
capable  units  (ADCU)  are  placed  in  the  list.  If  the  unit  is  moving,  it  is 
not  included  in  the  list.  The  total  number  of  units  in  the  list  is  also 
returned. 

b.  Input  Variables: 

(1)  Standard  Common  Block  Areas.  BPOINT,  RPOINT,  INTERR,  and  I EVENT 


(2)  Other  Variables: 


Name 

Source 

Contents 

UID 

Call 

Identification  of  the  unit  requesting  the 
search. 

X 

Call 

X  coordinate  of  the  center  of  the  area  to  be  : 

searched. 
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Figure  IV-15-B-26.  Routine  CIRCLE 
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Name 


Source 


Contents 


Y  Call  Y  coordinate  of  the  center  of  the  area  to  be 

searched . 

S  Call  Radius  of  search  area. 

JMAX  Call  Maximum  number  of  enemy  units  to  be  listed. 

c.  Output  Variables: 

Name  Destination  Contents 

UNTLST  Call  List  of  IUIDs  of  enemy  units  found. 

J  Call  Total  number  of  IUIDs  in  UNTLST. 

d.  Logical  Flow  (Figure  IV-15-B-27): 

(1)  Block  1.  Square  the  radius  of  the  search  area  (S)  to  determine 
size  of  search  area. 

(2)  Block  2.  Determine  whether  the  requesting  unit  is  Red  or  Blue 
force,  and  initialize  the  starting  and  ending  values  of  the  loop  utilizing 
BPOINT  or  RPOINT. 

(3)  Block  3.  Determine  if  unit  is  a  resolution  unit. 

(4)  Blocks  4,  5,  and  L5.  If  the  third  character  of  the  unit  type 
designator  is  M,  or  the  fourth  character  of  the  unit  type  designator  is  D, 
GETEVT  is  called  to  return  the  event  code. 

(5)  Block  6.  If  the  event  code  is  equal  to  two,  the  unit  is  moving 
and  control  transfers  to  block  11. 

(6)  Block  7.  Calculate  the  distance  from  the  search  center. 

(7)  Block  8.  If  the  unit  is  not  in  the  search  area,  control  transfers 
to  block  11. 

(8)  Block  9.  Compare  the  number  of  units  in  the  list  with  JMAX  to 
determine  if  the  unit  list  is  full.  If  so,  control  returns  to  the  calling 
routine;  otherwise,  control  goes  to  block  10. 

(9)  Block  10.  Add  the  unit  to  the  list  and  increment  the  unit 
counter  by  one. 

(10)  Block  11.  If  this  unit  was  the  last  enemy  unit,  control  returns 
to  the  calling  routine;  otherwise,  control  transfers  to  block  3. 
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31.  ROUTINE  ATTDVR : 


a.  Purpose.  This  routine  is  the  driving  routine  for  in-flight  attrition. 
It  initializes  the  event  record,  updates  the  unit's  status  record,  and  calls 
the  appropriate  overlay. 

b.  Input  Variables: 


Name 


FILE12(35) 


Source 


TWO 


Contents 

Automatic  event  description  record. 

FILE12(1).  Operation  code  for  this  unit. 

FILE12 (4)  or  FILE12(5).  IUID  of  the  mission 
unit . 

FILE12(31).  Record  used  in  data  file  7. 

FILE12(32).  Flight  leg  indicator:  2  = 
last  flight  leg;  0  =  another  flight  segment. 

FILE12(35).  Operation  code  for  the  next 
operation. 


c.  Output  Variables: 

(1)  Standard  Common  Block  Variable:  UMAIN. 

(2)  Other  Variables: 


Name 


FILE12 (35) 


Destination  Contents 

TWO  Automatic  event  description  record. 

FIL£12(32).  Flight  leg  indicator; 
last  flight  leg;  0  =  otherwise. 


7  - 


FILE12(31).  Record  used  on  data  file  7. 


FILE12(1).  Operation  code, 

d.  Logical  Flow  (Figure  1V-15-B-28): 

(1)  Blocks  1  and  2.  Get  the  IUID  of  the  mission  unit  from  FILE12. 
The  IUID  is  in  word  four  of  FILE12  if  the  event  code  (IEC)  is  equal  to  13  and 
the  next  operation  code  (IPROG)  is  between  20  and  30;  otherwise,  the  IUID  is 
in  word  five.  Get  the  unit's  status  record  from  data  file  1. 

(2)  Blocks  3  and  4.  Determine  if  any  transport  equipment  is  on 
hand  and  transfer  control  to  block  8  if  the  equipment  is  present.  If  escort 
equipment  is  on  hand,  transfti  -.ontrol  to  block  8. 
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Figure  IV-15-B-28. 


Routine  ATTDVR  (Continued  on  Next  Page) 
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Figure  IV-15-B-28.  Routine  ATTDVR  (Concluded) 


(3)  Blocks  5,  L89,  and  6.  Check  to  determine  if  this  is  a 
reconnaissance  mission.  If  it  is,  set  FILE12(1)  to  the  next  operation  code 
(IPROG)  and  call  EVTSET  to  schedule  the  next  event. 

(4)  Blocks  7  and  L57.  If  a  data  file  7  record  does  not  exist,  one 
is  assigned.  Initialize  the  IWORK  array  and  put  it  on  data  file  7. 

(5)  Block  L15.  Set  appropriate  FILE12  values  to  zero. 

(6)  Block  8.  Calculate  the  distance  and  move  rate. 

(7)  Block  13.  Check  to  detjrmine  if  an  event  record  was  assigned. 

(8)  Blocks  9  and  10.  Locate  an  empty  event  record,  initialize 
the  IWORK  array,  and  put  it  on  data  file  7. 

(9)  Block  L70.  Put  the  unit's  status  record  on  data  file  1. 

(10)  Blocks  11,  L300,  and  12.  Determine  which  overlay  segment  to 
call.  Call  the  appropriate  overlay,  and  return  control  to  the  calling 
routine . 

32.  ROUTINE  MES : 

a.  Purpose.  This  routine  identifies  major  engagement  segments  (MES) 
of  a  flight  leg  where  attrition  can  occur.  If  the  aircraft  reaches  the  end 
of  the  flight  leg  with  no  possible  engagement  segments  found,  the  coordinates 
of  the  air  unit  are  updated  to  the  end  of  the  flight  leg  and  an  event  is  set 
for  the  time  the  air  unit  reaches  the  end  of  the  flight  leg.  A  major 
engagement  segment  (MES)  is  determined  when  there  is  a  change  in  the  total 
number  of  units  capable  of  firing  or  the  total  number  of  weapons  firing. 

b.  Input  Variables: 

(1)  Standard  Common  Block  Variable.  UMAIN. 

(2)  Other  Variables: 

Name  Source  Contents 

JPASS  TWO  Flight  leg  indicator: 

0  »  initial  flight  leg 

1  =  intermediate  flight  leg 

2  »  last  flight  leg 

9  ■  Airmobile  event  call. 


IOPER 

TWO 

Unit 

's  operation  code. 

NEXTOP 

TWO 

Next 

operation  code. 

MSNUNT 

TWO 

IUID 

of  mission  unit. 

IRANGE 


DF7 


Range  of  a  particular  weapon. 


Name 


Source 


Contents 


NITCAP 

DF7 

Night  capability  of  an  air  defense  weapon. 

NWECAP 

DF7 

Weather  capability  of  an  air  defense  weapon, 

MAXALT 

DF7 

Maximum  altitude  of  an  air  defense  weapon. 

MINALT 

DF7 

Minimum  altitude  of  an  air  defense  weapon. 

MAXSPD 

DF7 

Maximum  speed  of  an  air  defense  weapon. 

MINSPD 

DF7 

Minimum  speed  of  an  air  defense  weapon. 

c . 

Output  Variables: 

(1) 

Standard  Common 

Block  Variables.  UMAIN 

(2) 

Other  Variables: 

Name 

Destination 

Contents 

IXB 

DF7 

X  coordinate  of  major  engagement  segment 
beginning. 

IYB 

DF7 

Y  coordinate  of  a  major  engagement  segment 
beginning . 

IXE 

DF7 

X  coordinate  of  a  major  engagement  segment 
end . 

IYE 

DF7 

Y  coordinate  of  a  rnajoi  engagement  segment 
end. 

MESST 

DF7 

Major  engagement  segment  start  time. 

LOSST 

DF7 

Line-of-sight  starting  time. 

IDELT 

DF7 

Elapsed  time  of  major  engagement  segment. 

JPASS 

DF12 

Flight  leg  indicator: 

0  •  initial  flight  leg 

1  «  intermediate  flight  leg 

2  -  last  flight  leg 

9  =  Airmobile  event  call. 

d. 

Logical  Flow  (Figure 

IV-15-B-29) : 

(1) 

Block  1.  Write 

FILE12 . 

(2) 

Block  2.  Bring 

in  the  GTAA  related  variables  and  put  them  in 

array  IWORK. 
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Figure  IV-15-B-29. 


Routine  MES  (Continued) 


IV-15-B-105 


2 


> 


» 


Figure  IV-15-B-29. 


Routine  MES  (Continued) 
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Figure  IV-15-B-29.  Routine  MES  (Continued) 
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FIe“"  IV-15-'-29-  HES  (Concluded) 
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(3)  Block  3.  Gee  the  unit  status  record  information  from  data  file 
1  and  put  it  in  UMAIN. 

(4)  Block  4.  Calculate  the  distance  of  the  flight  leg,  the  current 
location  and  the  location  at  the  end  of  the  flight  leg. 

(5)  Block  5.  Develop  a  list  of  air  defense  weapon  item  codes  from 
the  data  on  data  file  7. 

(6)  Block  6.  Call  WETTHR  to  get  the  weather  index. 

(7)  Block  8.  Determine  if  a  certain  type  of  weapon  is  effective  in 

the  present  weather  and  light  conditions. 

(8)  Block  9.  Check  to  determine  if  the  aircraft  is  within  the 
limits  of  this  weapon  type. 

(9)  Block  10.  Determine  if  the  aircraft  speed  is  within  the 
capability  limits  of  this  weapon  type. 

(10)  Blocks  11  and  12.  Increment  the  number  of  satisfactory  weapon 
types  (JNUM)  by  one  and  store  this  weapon  code  and  its  range. 

(11)  Block  L25.  Determine  if  this  is  the  end  of  the  weapons  list. 

(12)  Block  L26.  Determine  if  the  number  of  air  defense  weapons  is 

greater  than  zero. 

(13)  Block  13.  Call  RANKA  to  rank  the  air  defense  weapons  with 
ranges  in  descending  order. 

(14)  Block  14.  Determine  is  JPASS  is  equal  to  zero  or  nine. 

(15)  Block  15.  Determine  whether  the  end  of  the  flight  leg  has  been 
reached  by  comparing  XACT  and  YACT  with  MEVTX  and  MEVTY. 

(16)  Block  16.  Compute  the  new  coordinates  of  a  look  point  and  set 
MES  beginning  coordinates.  The  radius  of  the  search  area  (RL00K)  is  also 
determined . 

(17)  Blocks  17  and  18.  If  the  new  coordinates  are  past  the  end  of 
the  flight  leg,  reset  the  coordinates  to  the  end  of  the  flight  segment. 

(18)  Block  L150.  Call  GASRCH  to  search  within  a  specified  radius, 
RLOOK,  for  enemy  units.  The  enemy  units  are  returned  in  LIST1  and  the  number 
of  units  in  II. 

(19)  Block  19.  Check  II  to  determine  if  the  number  of  enemy  units 
in  the  area  is  greater  than  zero. 

(20)  Block  20.  Determine  whether  or  not  the  end  of  the  flight  leg 
has  been  reached  by  the  look  point. 
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(21)  Blocks  22  and  L175.  If  JSWCH  Is  equal  to  one,  control 
transfers  to  block  L175,  where  the  time  increment  (INCTIM)  is  added.  JSWCH 
equal  to  one  indicates  a  major  engagement  segment  start  has  not  been  found. 

(22)  Block  23.  Transfer  control  to  an  appropriate  block  depending 
on  the  value  of  JSWCH.  If  JSWCH  is  greater  than  one,  a  major  engagement 
segment  start  has  been  found. 

(23)  Blocks  24  and  25.  Test  the  value  of  RLOOK;  if  the  altitude  of 
the  aircraft  is  greater  than  15,000  feet,  only  air  defense  capable  units 
(ADCU)  are  checked. 

(24)  Block  26.  Get  the  unit  status  record  of  the  enemy  unit  from 
data  file  1  and  put  it  in  UCOOP. 

(25)  Block  27.  Determine  whether  the  enemy  unit  possesses  any 
weapons  in  the  list. 

(26)  Block  28.  Compute  the  distance  from  the  enemy  unit  to  the 
aircraft . 

(27)  Blocks  29  and  30.  If  the  aircraft  is  within  range  of  the 
weapon  type  and  the  aircraft  is  in  line  of  sight  of  the  enemy,  a  major 
engagement  segment  has  been  found. 

(28)  Blocks  31  and  32.  Transfer  control  to  an  appropriate  block 
depending  on  the  value  of  JSWCH  and  set  JSWCH  equal  to  two  if  its  previous 
value  was  one. 

(29)  Blocks  33  and  60.  Put  the  IUID  of  the  enemy  unit  in  LIST3. 

If  JSWCH  is  equal  to  three,  put  succeeding  enemy  units  in  LIST4.  This  enables 
the  routine  to  detect  a  new  major  engagement  segment  when  13  does  not  equal 
14  or  LIST3  does  not  equal  LIST4. 

(30)  Block  34.  Transfer  control  to  the  appropriate  block  depending 
on  the  value  of  JSWCH. 

(31)  Block  L325.  Set  JSWCH  equal  to  three  and  increment  the  time. 

(32)  Blocks  35  and  L44Q.  If  JSWCH  is  greater  than  one,  set  the 
major  engagement  segment  end  point  coordinates,  I0PER,  and  the  event  code. 

(33)  Block  36.  Set  the  coordinates  of  the  unit  to  the  end  of  the 
flight  leg  and  schedule  the  event  to  return  to  the  calling  routine  when  the 
air  unit  reaches  the  end  of  the  flight  leg.  The  unit  is  moved  up  at  Chat 
time. 

(34)  Blocks  37  and  38.  A  value  of  INX  equal  to  one  or  three, 
indicates  a  reconnaissance  event,  and  when  the  end  of  the  flight  leg  is 
reached,  the  data  file  7  record  is  zeroed. 
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(35)  Blocks  39  and  40.  If  this  is  not  an  intermediate  leg  (JPASS 
greater  than  two)  or  this  call  was  from  reconnaissance,  the  data  file  12 
record  pointer  is  set  to  zero. 

(36)  Block  L450.  Call  EVTSET  to  schedule  an  event  that  will  return 
control  to  the  calling  routine  when  the  end  of  the  flight  leg  is  reached. 

(37)  Blocks  41  and  42.  If  routine  SIS  is  not  to  be  called  next 
(I0PER  not  equal  to  52),  or  this  is  the  last  flight  leg  (JPASS  less  than  two), 
zero  the  IWORK  array. 

(38)  Blocks  L500  and  43.  If  13  is  not  equal  to  14  or  LIST3  is  not 
equal  to  LIST4,  a  major  engagement  segment  ending  has  been  found.  These 
conditions  indicate  a  change  in  the  constant  weapon-unit  combinations. 

(39)  Block  44.  Zero  LIST4 . 

(40)  Blocks  45  and  46.  If  the  unit  is  not  at  the  end  of  the  flight 
leg,  set  JSWCH  equal  to  two. 

(41)  Blocks  L575,  47,  and  48.  Set  the  end  points  for  the  major 
engagement  segment  and  set  the  variables  required  in  the  call  to  SIS.  Call 
EVTSET. 


(42)  Blocks  49  and  50.  Put  the  major  engagement  segment  data  on 
data  file  7  and  put  the  unit's  status  record  on  data  file  1. 

33.  ROUTINE  SIS: 


a.  Purpose.  Routine  SIS  is  called  in  response  to  the  events  initiated 
in  MES.  SIS  updates  the  position  of  the  air  unit  to  the  location  of  the 
start  of  this  segment  of  the  flight  leg.  The  primary  task  of  SIS  is  to 
examine  the  current  status  and  air  defense  capability  of  each  air  defense 
weapon  system  expected  by  MES  to  be  capable  of  participating  in  this  segment 
of  the  flight  leg.  This  examination  reveals  subsegments  called  constant 
fire  segments  (FS)  or  intercept  segments  (IS)  in  which  weapons  are  capable 
of  delivering  projectiles  that  will  intercept  the  air  unit  during  this 
segment  of  the  flight  leg. 


b. 


Name 


Input  Variables: 

(1)  Standard  Common  Block  Variables.  UMAIN  and  UCOOP. 

(2)  Other  Variables: 

Source  Contents 


FILE12(35)  TWO 

IOPER 

MISNUNT 


Event  description  record. 

FILE12(1).  Unit  operation  code. 
FILE12(34).  IUID  of  the  mission  unit. 
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Name 

Source 

Contents 

JPASS 

FILE12(32).  Flight  leg  indicator: 

0  =  initial  flight  leg 

1  =  intermediate  flight  leg 

2  =  last  flight  leg 

9  =  Airmobile  event  call. 

NEXTOP 

FILE12(35).  Next  operation  code. 

13 

DF7 

Number  of  air  defense  capable  units  in  this 
segment . 

LIST3 

DF7 

List  of  air  defense  capable  units  in  this 
segment . 

IXB 

DF7 

Beginning  X  coordinate  of  major  engagement 
segment. 

IYB 

DF7 

Beginning  Y  coordinate  of  major  engagement 
segment. 

IXE 

DF7 

Ending  X  coordinate  of  major  engagement 
segment . 

IYE 

DF7 

Ending  Y  coordinate  of  major  engagement 
segment . 

MESST 

DF7 

Major  engagement  segment  starting  time. 

LOSS! 

DF7 

Line-of-sight  starting  time. 

IDELT 

DF7 

Elapsed  time  of  major  engagement  segment. 

LASTET 

DF7 

Time  of  last  constant  fire  sent  Co  GTAA. 

IDELYT 

DF7 

Delay  time  until  weapon  can  start  firing. 

WEPRNG 

DF7 

Weapon  range. 

MUZVEL 

DF7 

Muzzle  velocity. 

DRAGF 

DF7 

Drag  coefficient  of  weapon. 

IRESPR 

DF7 

Radius  of  area  of  responsibility. 

MUNITN 

DF7 

Munition  type. 

IBOUND(l) 

DF7 

Lock-on  boundary. 
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c.  Output  Variables: 

(1)  Standard  Common  Block  Variables.  UMAIN  and  UCOOP. 

(2)  Other  Variables: 


Name  Destination 

ISREC  DF7 


FILE12 (35)  DF12 

IOPER 

JREC 


LASTET  DF7 


Contents 


Constant  fire  data  from  SIS: 

Word  1  =  beginning  fire  time 

Word  2  =  ending  fire  time 

Word  3  ■  IUID  of  air  defense  capable  unit 

Word  4  =  weapon  type. 

Event  description  record. 

FILE12(1).  Unit's  operation  code. 

FILE12(31).  Pointer  to  record  on  data  file  7 
of  ISREC  values,  packed  into  two  rightmost 
digits  of  FILE12(31). 

Time  of  last  constant  fire  sent  to  GTAA. 


d.  Logical  Flow  (Figure  IV-15-B-30) : 

(1)  Block  1.  A  message  starting  the  SIS  mission  unit  is  written. 

(2)  Block  2.  Bring  in  the  air  defense  capable  unit  and  weapon  data 
from  data  file  7. 


(3)  Block  3.  The  length  of  the  major  engagement  segment  is  calculated 
by  calling  routine  RANGEF  and  passing  it  the  coordinates  of  the  beginning 

and  ending  major  engagement  segments. 

(4)  Block  4.  The  unit  status  record  for  the  mission  unit  is  brought 
in  from  data  file  1  and  stored  in  UCOOP. 

(5)  Block  5.  The  major  engagement  segment  end  time  (MESEND)  is 
calculated  by  adding  IDELT  to  MESST. 

(6)  Block  6.  The  air  unit  is  moved  to  the  major  engagement  segment 
beginning  coordinates. 

(7)  Block  7.  If  JPASS  is  greater  than  zero  and  JPASS  is  not  equal 
to  nine,  this  is  an  intermediate  leg. 

(8)  Blocks  8  and  9.  It  this  is  an  Airmobile  event,  JPASS  is  set  to 
two  to  indicate  the  data  file  7  record  should  be  zeroed  at  the  end  of  the 
flight  leg. 

(9)  Blocks  10  and  12.  If  this  is  not  the  last  flight  leg,  set  the 
last  event  time  to  the  major  engagement  segment  start  time.  Also,  since  this 
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Figure  IV-15-B-30. 


Routine  SIS  (Continued  on  Next  Page) 
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Figure  IV-15-B-30.  Routine  SIS  (Continued) 
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Figure  IV-15-B-30.  Routine  SIS  (Concluded) 
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is  Che  initial  flight  leg,  the  work  arrays — TEMPI,  TEMP2,  and  TEMP  3 — Chat 
are  used  to  set  up  constant  fire  events  for  GTAA  are  zeroed. 

(10)  Block  11.  Because  this  is  an  intermediate  flight  leg,  the 
.ait  event  time  is  obtained  from  data  file  7. 

(11)  Block  13.  Obtain  the  unit  status  record  of  an  enemy  unit  from 
data  file  1  and  put  it  in  UMAIM . 

(12)  Block  14.  Call  PCN'TLM  to  get  the  crossover  point. 

(13)  31ock  15.  Obtain  a  weapon  item  code  from  array  IKEPM. 

(14)  Block  16.  If  the  enemy  unit  does  not  possess  this  weapon, 
control  is  transferred  to  the  end  of  the  weapon  loop. 

(15)  Block  17.  This  block  adds  half  of  the  width  or  the  depth — 
whichever  is  less — to  the  maximum  range  of  the  weapon. 

(16)  Block  18.  If  the  weapon's  maximum  range  is  less  than  the 
distance  between  the  air  unit  and  the  enemy  unit  (SEP),  control  is  transferred 
to  the  end  of  the  weapon  loop. 

(17)  Block  19.  Control  is  transferred  to  the  end  of  the  weapon 
loop  if  the  aircraft  is  not  in  the  area  of  responsibility  of  the  enemy  unit 
(IRESPR). 

(18)  block  20.  Transfer  control  to  the  end  of  the  weapon  loop  if 
the  quantity  of  this  weapon  is  less  than  0.5. 

(19)  Block  21.  Determine  if  the  enemy  unit  possesses  the  munition 
type  required  by  this  weapon. 

(20)  31ock  22.  Calculate  the  horizontal  aspect  angle  to  the 
beginning  of  the  major  engagement  segment. 

(21)  Block  23.  If  the  weapon  is  an  infrared  missile,  determine  if 

the  major  engagement  segment  is  within  the  maximum  lock-on  boundary  (IBOUMD(l)). 

(22)  Block  24.  If  the  aircraft  speed  exceeds  the  slew  rate  of  the 
weapon,  control  is  transferred  to  the  end  of  the  weapon  loop. 

(23)  31ock  25.  Call  CHORD  to  determine  the  coordinates  of  the 
weapon  range  and  flight  leg  intersection. 

(24)  Block  26.  Process  the  points  where  the  weapon  can  begin  firing 
ar.c  end  firing.  Determine  these  points  utilizing  the  enemy  unit's  location 
and  the  range  and  characteristics  of  the  weapon. 

(25)  Block  27.  Set  the  value  of  IFLAG  to  one  for  a  beginning  fire 
time  and  two  for  an  ending  fire  time. 
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(26)  Block  28.  Puc  the  air  defense  capable  unit  IUID,  weapon  type, 
beginning  fire  time,  and  beginning  flag  code  in  array  TEMPI.  This  is  also 
done  for  the  ending  fire  time. 

(27)  Block  29.  The  beginning  and  ending  fire  times  are  written. 

(28)  Block  L350.  This  block  is  the  end  of  the  weapon  loop.  If  the 

list  is  not  exhausted,  control  is  returned  to  the  beginning  of  the  loop. 

(29)  Block  L400.  The  block  is  the  end  of  the  ADCU  loop.  If  the 

list  is  not  exhausted,  control  is  returned  to  the  beginning  of  the  loop. 

(30)  Block  30.  Routine  RANKA  is  called  to  rank  the  TEMPI  entries 
by  increasing  event  times. 

(31)  Block  31.  Using  the  arrays  TEMPI,  TEMP2 ,  and  TEMP3 ,  process 

the  events  into  r’.ie  ranked  order  and  format. 

(32)  Block  32.  Put  the  data  from  the  above  arrays  in  array  ISREC. 
Each  entry  of  ISREC  contains  four  words.  Also,  the  value  of  JREC  is 
established.  A  total  of  ISNUM  of  these  records  will  be  created. 

(33)  Block  33.  Schedule  an  automatic  (FILE12)  event  for  GTAA. 

(34)  Blocks  L701  and  34.  If  the  aircraft  is  at  the  end  of  the 
flight  leg,  update  the  unit's  coordinates  to  the  end  of  the  flight  leg. 

(35)  Block  35.  Put  the  mission  unit's  status  record  on  data  file  1. 

(36)  Block  36.  Set  an  automatic  (FILE12)  event  to  call  MES  at  the 
last  event  time. 

(37)  Block  37.  The  updated  record  to  be  used  in  GTAA,  including 
array  ISREC,  is  put  on  data  file  7. 

34.  ROUTINE  GTAA: 

a.  Purpose.  GTAA  is  called  in  response  to  the  attrition  event 
scheduled  in  SIS.  3ased  on  the  data  derived  from  the  constant  fire  segment 
(CFS)  generated  in  SIS,  status  adjustments  are  made  and  weapon  capabilities 
are  elaborated  to  approximate  average  capability  over  the  constant  fire 
segment.  Suppressive  fire  and  effects  on  air  defense  weapons  are  accounted 
for. 

b.  Input  Variables: 

(1)  Standard  Common  Block  Variables.  UMAIN  and  UC00P. 
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(2) 


Other  Variables: 


Name 

Source 

Contents 

IXB 

DF7 

Beginning  X  coordinate  of  a  major  engagement 
segment . 

IYB 

DF7 

Beginning  Y  coordinate  of  a  major  engagement 
segment . 

MESST 

DF7 

Time  of  a  major  engagement  segment  start. 

IXE 

DF7 

Ending  X  coordinate  of  a  major  engagement 
segment . 

IYE 

DF7 

Ending  Y  coordinate  of  a  major  engagement 
segment . 

IDELT 

DF7 

Elapsed  time  of  a  major  engagement  segment. 

LASTET 

DF7 

Last  event  time. 

IOPER 

TWO 

Unit’s  operation  code. 

MSNUNT 

TWO 

FILE12(1),  FILE12 (31) ,  and  FILE12(34).  IUID 
of  the  mission  unit. 

KREC 

TWO 

Pointer  to  this  unit's  record  on  data  file  7 

DIVERT 

DF7 

Distance  that  escorts  are  allowed  to  divert 
from  a  path. 

ACDATA 

DF7 

Aircraft  data. 

MISTM 

DF7 

Suppression  mission  duration  time. 

ESCDT 

DF7 

Escort  delay  time. 

I SLANT 

DF7 

Maximum  slant  range  for  the  weapon  system. 

MUZVEL 

DF7 

Muzzle  velocity  of  a  weapon. 

DRAGF 

DF7 

Drag  coefficient. 

IBOUND(l) 

DF7 

Lock-on  boundary  of  a  missile. 

BRSTRN 

DF7 

Number  of  rounds  per  burst. 

BRSTRT 

DF7 

Burst  rate,  in  rounds  per  minute. 

DRSTDL 

DF7 

Interburst  delay  time. 

MAGCAP 

DF7 

Magazine  capability  in  rounds. 
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Source 

Contents 

RELDEL 

DF7 

Reload  delay  time. 

RELY? 

DF7 

Reliability  factor. 

VISDEG 

DF7 

Weather  visibility  degradation. 

ECMF 

DF7 

Electromagnetic  countermeasure  fraction. 

I  SLEW 

DF7 

Vertical  slew  rate. 

ISLEWH 

DF7 

Horizontal  slaw  rate. 

WRITE 

DF7 

Munition  type. 

I  FLAG 

DF7 

Weapon  flag. 

AVMIL 

DF7 

Average  miss  distance  for  a  missile,  in 
artillery  mils. 

MPKDAT 

DF7 

Missile  probability  of  kill  data  segment. 

ERDXIS 

DF7 

X  coordinate  of  end  of  an  intercept  segment. 

ERDYIS 

DF7 

Y  coordinate  of  end  of  an  intercept  segment. 

c . 

Output  Variables: 

(1) 

Standard  Common 

Block  Variables.  UMAIE  and  UCQOP. 

(2) 

Other  Variables 

• 

Eame 

Destination 

Contents 

PSPROD 

TWO 

Survival  probability  product  of  aircraft. 

pkm 

TWO 

Kill  probability  for  a  missile. 

? ILE12 

TWO 

Automatic  event  cable. 

N'ADCU 

TOO 

Eumber  of  air  defense  capable  units. 

ERDXIS 

TWO 

End  X  coordinate  of  an  intercept  segment. 

ERDYIS 

TWO 

End  Y  coordinate  of  an  intercept  segment. 

d. 

Logical  Flow  (Figure 

IV-15-B-31) : 

(1) 

Block  1.  GTAA 

is  written. 

(2) 

Block  2.  Zero 

two  probability  arrays,  PKM  and  PSPROD.  PXM  is 

Che  probability  of  a  kill  for  a  missile  and  PSPROD  is  the  probability  of 
survival  for  an  aircraft. 
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Figure  IV-15-B-31.  Routine  GTAA  (Continued  on  Next  Page) 
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Figure  IV-15-B-31.  Routine  GTAA  (Continued) 
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Figure  IV-15-B-31.  Routine  GTAA  (Continued) 
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Figure  IV— 15— B— 31*  Routine  GTAA  (Continued) 
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Figure  IV-15-B-31 .  Routine  GTAA  (Continued) 
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Figure  IV-15-B-J1.  Routine  GTAA  (Concluded) 
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(3)  Block  3. 
and  put  it  in  UMAIN. 


Get  the  mission  unit's  status  record  from  data  file  1 


(4)  Block  4.  Bring  in  the  air  defense  weapon  table  (IWEPN). 

The  data  generated  in  SIS  is  put  in  the  array  IWORK 


(5)  Block  5. 
from  data  file  7. 

(6)  Block  6. 
intercept  segment. 

(7)  Block  7. 
intercept  segment. 


Calculate  the  beginning  and  ending  coordinates  of  an 
Write  the  beginning  and  ending  coordinates  of  the 


(8)  Block  8.  Count  air  defense  capable  units  expected  to  participate 
in  the  intercept  segment  and  save  their  identifications  on  the  array  ID. 

(9)  Block  L103.  Initialize  a  loop  on  the  air  defense  capable  units. 
The  air  defense  capable  units  are  examined  one-at-a-time . 


(10)  Block  9.  Bring  in  the  air  defense  capable  unit  status  record 
from  data  file  1  and  put  it  in  UC00P. 

(11)  Blocks  10  and  11.  Get  the  suppression  duration  time  and  the 
GTAA  general  and  aircraft  data  from  data  file  7.  Set  the  suppression  interval 
for  the  TACAIR  ground-based  artillery. 

(12)  Block  12.  Calculate  the  suppression  intervals  of  the  air  defense 
capable  unit  caused  by  the  escorts. 

(13)  Block  13.  Determine  whether  the  suppression  intervals  are 
outside  of  the  intercept  segment. 

(14)  Block  14.  The  maximum  suppression  interval  is  calculated. 

(15)  Block  15.  Tht  total  suppression  overlap  fraction  is  calculated. 

(16)  Block  16.  If  the  air  defense  capable  unit  suppression  lasts  to 
the  end  of  the  intercept  segment,  control  is  transferred  to  the  end  of  the 
air  defense  capable  unit  loop. 

(17)  Block  17.  If  the  flight  or  serial  has  already  passed  the  point 
where  it  can  call  for  escorts  (no  request  point) ,  control  is  transferred  to 
block  21. 

(18)  Blocks  18  and  19.  If  two  escorts  are  not  available,  write  the 
total  number  of  escorts  on  hand  and  transfer  control  to  block  21. 

(19)  Block  20.  Set  the  escort  suppression  start  and  lapse  times; 
then,  transfer  control  to  block  12  to  recalculate  the  total  suppression 
fraction. 
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(20)  Block  21.  Determine  the  mid  point  of  the  intercept  segment 
and  calculate  other  geometries  from  the  air  defense  capable  unit  to  be  used 
later . 

(21)  Block  22.  Using  the  geometries  calculated  in  block  21, 
calculate  the  weapons  slew  rates  in  radians  per  centiminute. 

(22)  Block  23.  Establish  the  direction  of  the  flight.  IDIREC  is 
set  to  one  if  the  flight  is  toward  the  air  defense  capable  unit  or  IDREC  is 
set  to  two  if  the  flight  is  away  from  the  air  defense  capable  unit. 

(23)  Block  24.  Given  the  angles  from  the  air  defense  capable  unit 
to  the  aircraft,  the  presented  area  (PA)  is  calculated  for  each  aircraft 
type. 


(24)  Block  25.  Calculate  an  average  maneuver  rate  for  a  given 
aircraft  using  the  aircraft  data  from  data  file  7. 

(25)  Blocks  26,  27,  and  28.  Determine  the  fraction  of  air  defense 
capable  unit  weapons  having  a  line  of  sight  to  the  aircraft.  If  the  ADCU 
is  in  a  fore  ted  area,  multiply  the  fraction  of  the  line  of  sight  (FRCLOS) 
by  0.75. 


(26)  Block  29.  Fill  the  number  of  weapons  on  hand  array.  This 
block  is  the  beginning  of  the  weapons  loop. 

(27)  Block  30.  If  the  aircraft  exceeds  the  weapon's  slew  rates, 
control  is  transferred  to  the  end  of  the  weapons  loop. 

(28)  Block  31.  Determine  the  fraction  of  the  air  defense  capable 
unit  within  range. 

(29)  Block  32.  Determine  the  total  number  of  weapons  capable  of 
firing  in  this  intercept  given  the  existing  conditions. 

(30) .  Block  33.  If  the  weapon  is  a  missile,  transfer  control  to 
block  39. 

(31)  Block  34.  Since  the  weapon  is  not  a  missile,  calculate  the 
total  amount  of  this  munition  type  to  be  fired  during  this  intercept  segment 
given  the  existing  conditions. 

(32)  Block  35.  Calculate  the  number  of  rounds  fired  per  aircraft 
during  this  flight  or  serial. 

(33)  Block  50.  Subtract  the  number  of  rounds  fired  for  this 
ammunition  type  from  the  equipment  on  hand. 

(34)  Block  36.  Calculate  the  vulnerable  areas  for  each  type  of 
aircraft. 

(35)  Block  37.  Depending  on  the  value  of  IFLAG,  control  is 
transferred  to  one  of  the  four  equation  sets  of  weapon  errors  for  guns. 
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(36)  Blocks  L410,  L420,  L430,  and  L440.  Calculate  the  weapon  errors. 
Four  sets  of  equations  are  used  to  approximate  the  weapon  error  associated 
with  four  types  of  gun  systems: 

.  Visually  sighted  12.7mm  or  0.50  caliber  machinegun 

.  Optically  directed  14.5mm,  23mm,  and  57mm  systems 

.  Range  only  radar  systems 

.  Full  solution  radar  systems. 

(37)  Block  38.  Calculate  the  probability  of  an  aircraft  surviving 
and  store  this  probability  in  array  PSPROD  which  is  used  by  LOSSES. 

(38)  Block  39.  Initialize  the  missile  calculations.  Calculate  a 
one-sigma  error  based  on  the  missile's  average  miss  distance. 

(39)  Block  40.  Determine  which  aircraft  has  the  largest  presented 

area. 

(40)  Block  41.  Given  the  presented  area,  sigma,  and  a  random  number, 
calculate  the  missile  miss  distance. 

(41)  Block  42.  Interpolate  the  probability  of  a  kill  (PK)  array  at 
the  calculated  miss  distance. 

(42)  Block  43.  Fill  the  probability  of  a  missile  kill  (PKM)  array 
with  data  from  the  PK  array  and  total  number  of  weapons  for  the  later  call 
to  LOSSES. 

(43)  Block  44.  Subtract  the  number  of  rounds  fired  from  the 
equipment  on  hand. 

(44)  Block  45.  Write  the  number  of  rounds  fired  and  the  probability 
of  a  missile  kill  (PKM)  array. 

(45)  Blocks  L698  and  L699.  These  blocks  are  the  end  of  the  weapon 
and  air  defense  capable  unit  loops. 

(46)  Block  46.  Zero  the  array  ISLIST  containing  the  air  defense 
capable  units,  their  weapon  types,  and  starting  and  ending  firing  times. 

(47)  Block  47.  Call  routine  LOSSES. 

35.  ROUTINE  LOSSES: 

a.  Purpose.  The  routine  LOSSES  determines  attrition  to  personnel  and 
equipment  based  on  the  sum  of  all  probabilities  of  kill  for  both  missiles  and 
guns,  places  the  lost  personnel  and  equipment  into  an  array  for  passage  to 
the  score  board  routine,  updates  the  coordinates  of  the  mission  unit  for  the 
aircraft,  and  puts  the  score  board  pointer  and  updated  equipment  array  back 
on  the  unit  status  file. 
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b.  Input  Variables: 


(1) 

Standard  Common 

Block  Area.  UMAIN. 

(2) 

Other  Variables: 

Name 

Source 

Contents 

PKM 

TWO 

Probability  of  kill  for 

missile 

type. 

PSPROD 

TWO 

Probability  of  survival 

product 

for  guns. 

ENDXIS 

TWO 

X  coordinate  of  unit  at 
engagement  segment . 

end  of 

this  major 

ENDYIS 

TWO 

Y  coordinate  of  unit  at 
engagement  segment. 

end  of 

this  major 

NADCU 

TWO 

Number  of  air  defense  capable  units 
encountered . 

c . 

Output  Variables: 

(1) 

Standard  Common 

Block  Variable.  IOUT. 

(2) 

Other  Variables. 

None. 

d. 

Logical  Flow  (Figure  IV-15-B-32) : 

(1)  Block  L96.  Initialize  necessary  variables  including  array  to 
be  used  for  scoring  losses  and  set  total  number  of  personnel  to  present 
strength  plus  suppressed  strength  plus  fraction  of  personnel. 

(2)  Blocks  1,  2A,  and  2B.  Escort  and  transport  aircraft  losses  are 
processed  separately  with  transport  aircraft  processed  first.  The  item 
code  of  each  type  of  aircraft  is  contained  in  the  AIRDAT  array  kept  on  the 
unit  status  record  for  this  mission  unit,  with  AIRDAT(2)  containing  the 
transport  item  code  and  AIRDAT(4)  containing  the  escort  item  code. 

(3)  Blocks  L705,  3,  4,  5,  6,  and  7.  Initialize  loop  through  the 
probability  of  kill  array  for  each  of  four  possible  types  associated  with 
each  of  15  permissible  mission  types.  The  aggregate  total  represents  the 
total  amount  of  aircraft  losses  for  this  major  engagement  segment.  Thu  ratio 
of  aircraft  lost  to  aircraft  remaining  is  computed  with  a  maximum  boundary  of 
1.0.  If  no  aircraft  were  lost,  control  transfers  to  block  L706.  The  total 
number  of  aircraft  lost  is  subtracted  from  the  total  aircraft  on  hand  to 
obtain  the  new  amount,  and  personnel  lost  are  subtracted  from  unit's  total 
personnel  to  obtain  unit's  present  strength. 

(4)  Blocks  8,  9,  10,  11,  L720,  and  L730.  Because  the  reconnaissance 
overlay  makes  the  decision  whether  a  unit  is  shot  down,  thereby  losing  both 
aircraft  and  equipment,  no  attrition  other  than  loss  of  aircraft  is  calculated 
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Figure  IV-15-B-32.  Routine  LOSSES  (Continued) 
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Figure  IV-15-B-32.  Routine  LOSSES  (Concluded) 
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by  LOSSES.  Branch  Co  block  L706  if  this  is  a  mission  unit  created  by  the 
reconnaissance  overlay.  Because  escort  aircraft  have  items  that  are  not 
carried  on  transport  aircraft,  separate  loops  assess  losses  for  items  on  the 
transport  aircraft  and  items  particular  only  on  the  escort  craft,  both  based 
on  the  ratio  previously  calculated.  The  MIX  table  is  used  to  distinguish 
escort  item  codes.  Losses  assessed  in  both  loops  are  placed  in  a  score  board 
array  to  be  summed  for  additional  losses,  rearranged,  and  passed  to  routine 


SCORE. 


(5)  Block  L706.  If  this  is  the  pass  for  transport  aircraft,  control 
returns  to  block  1. 

(6)  Blocks  12,  13A,  13B,  14,  L712,  and  15.  Repeat  the  same  type  of 
logic  described  in  the  previous  paragraph,  accumulating  and  assessing  losses 
due  to  guns.  Determine  whether  to  assess  transport  or  escort  aircraft. 
Initialize  loop  through  the  four  probability  of  survival  products  for  guns 
and  sum  the  aggregate  aircraft  losses.  Compute  the  loss  ratio  of  aircraft 
lost  to  aircraft  on  hand,  and  subtract  the  aircraft  and  personnel  losses  from 
the  current  amounts. 

(7)  Blocks  16,  17,  18,  L740,  L750,  and  L715.  Bypass  the  assessment 
of  equipment  if  this  is  a  reconnaissance  unit  with  control  branching  to  block 
L715.  Separate  loops  process  the  attrition  of  equipment  on  the  transport 
and  escort  aircraft  sequentially.  If  processing  losses  for  the  transport 
aircraft,  control  branches  to  block  12  to  assess  escort  aircraft  for  guns. 

(8)  Blocks  19,  L810,  and  20.  After  replacing  the  current  strength 
of  personnel  and  amounts  of  equipment  (including  number  of  aircraft)  back 
onto  the  unit  status  file,  update  the  unit's  coordinates  to  its  location  at 
the  end  of  this  segment,  placing  the  coordinates  onto  both  the  unit  status 
file  and  into  the  location  array  stored  in  common.  If  this  is  a  reconnaissance 
mission  unit,  that  will  be  assessed  and  scored  by  the  reconnaissance  overlay, 
control  returns  to  the  calling  routine. 

(9)  Blocks  L467  and  21.  The  mission  unit's  origin,  rather  than  its 
superior  unit,  is  considered  when  determining  which  unit  should  be  assessed 
the  calculated  losses  as  follows: 

(a)  If  the  unit  being  assessed  is  not  a  model-generated  mission 
unit,  losses  are  assessed  directly  to  the  unit. 

(b)  If  the  unit  being  assessed  is  a  model-generated  mission 
unit  and  the  unit  has  escorts  and  transports  from  the  same  airbase,  losses 
are  assessed  to  the  airbase. 

(c)  If  the  unit  being  assessed  is  a  model-generated  mi.-sion  unit 
and  the  unit  has  escorts  from  one  airbase  and  transports  from  a  second  airbase, 
losses  for  escorts  are  assessed  to  the  airbase  providing  escorts,  and 
transport  losses  assessed  to  the  airbase  providing  transports.  Once  the 
appropriate  unit  for  scoring  has  been  selected,  and  the  lost  equipment  array 
rearranged,  routine  SCORE  updates  the  score  board  for  this  unit,  and  returns 
control  to  the  calling  routine. 
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APPENDIX  C 


AIRMOBILE  MODEL  OUTPUT  DESCRIPTIONS 


1.  INTRODUCTION.  This  appendix  contains  samples  and  detailed  descriptions  of 
printed  output  from  routines  within  the  Airmobile  Model  of  the  Period  Processor. 
The  output  of  each  routine,  depicted  by  a  figure,  is  explained  in  the  following 
paragraphs . 

2.  ROUTINE  ACCPT1 . 

a.  A  sample  of  the  printed  output  from  routine  ACCPT1  is  presented  in 
Figure  IV-15-C-1.  Each  print  group  is  identified  by  an  alphabetic  descriptor 
and  explained  below.  Unless  otherwise  stated,  the  listed  print  statements 
are  keyed  to  print  switch  2. 

Output 

Descriptor  Explanation 

A  The  airmobile  mix  table  is  printed.  The  entries  of  this  table 

are  defined  in  paragraph  4  of  Appendix  B  to  this  chapter. 

B  The  numerical  weather  code  for  the  existing  weather  conditions 

(0-3).  This  value  is  printed  by  routine  WETTHR  and  is  not 
keyed  to  a  print  switch. 

C  The  list  of  all  eligible  airbases  in  the  force  is  printed  with 

the  unit  identification  numbers  and  coordinates. 

D  The  speed  (knots)  and  fuel  consumption  rates  (gallons  per  hour) 

for  the  transport  aircraft. 

E  The  identification  number  of  each  candidate  airbase  is  printed 

as  it  is  considered  in  order  of  preference. 

F  The  total  fuel  required  for  all  transport  aircraft. 

G  Selection  type  code  (1  ■  source  of  escort  aircraft,  2  *  source 

of  transport  aircraft,  3  «  source  of  all  aircraft). 

H  This  group  of  print  is  produced  by  routine  PENRAT  and  lists: 

.  The  identification  number  of  the  forwardmost  enemy 
battalion 

.  Distance  from  the  safe  point  to  the  pickup  point  in 
meters 

.  Intercept  of  line  parallel  to  the  FEBA  trace  and  passing 
through  the  safe  point  with  the  X  axis 
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.  Intercept  of  line  parallel  to  the  FEBA  trace  and  passing 
through  the  pickup  point  with  the  X  axis 

.  The  difference  between  the  two  preceding  values 

.  Projection  of  the  safe  distance  onto  the  X  axis 

This  group  of  print  is  not  keyed  to  a  print  switch. 

I  The  game  time  delay  until  the  mission  unit  is  to  arrive  at  the 

pickup  point  in  centiminutes ,  the  time  required  to  fly  to  the 
safe  point  or  pickup  point  in  centiminutes,  and  the  gallons 
of  fuel  consumed  en  route. 

J  The  automatic  event  description  (TILE12  array)  contains  the 

following  information: 


Word 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

15 

35 

b.  Additional  printed  output  no 
below. 


Content 

Operation  code 
Unit  accepting  transport 
Airmobile  mix  number 
Number  of  transport  aircraft 
Mission  unit  identification 
Number  of  escort  aircraft 
Pickup  time 

Escort  mission  unit  identification 
Transport  mission  unit  identification 
Combined  mission  unit  identification 
Force  (1  =  Blue,  2  »  Red) 

Transport  aircraft  item  code 
Fuel  consumed 

Transport  aircraft  fuel  consumption 
rate 

In-flight  attrition  return  operator 
present  in  the  example  are  described 
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(1)  If  the  number  of  trips  has  been  specified,  the  weight  and  volume 

of  the  unit,  weight  and  volume  capacity  of  each  transport  aircraft,  and  required 
number  of  transport  aircraft  are  printed  between  descriptors  A  and  B. 

(2)  If  the  escort  and  transport  aircraft  are  selected  from  different 
airbases,  the  time  required  for  the  escort  aircraft  to  fly  to  the  transport 
airbase  is  printed  before  descriptor  J. 

3.  ROUTINE  ACCPT2.  A  sample  of  the  printed  output  from  routine  ACCPT2  is 
presented  in  Figure  IV-15-C-2.  All  output  has  been  described  in  the  preceding 
paragraph. 


4.  ROUTINE  ACCPT3.  The  only  output  from  routine  ACCPT3  is  the  automatic 
event  descriptor  (FILE12  array)  defined  above. 


5.  ROUTINE  ASULT1.  A  sample  of  the  printed  output  from  routine  ASULT1  is 
presented  in  Figure  IV-15-C-3.  Each  print  group  is  identified  by  an  alpha¬ 
betic  descriptor  and  explained  below.  All  output  is  keyed  to  print  switch  2. 


Output 

Descriptor 


Explanation 


A  The  alphanumeric  identification  of  the  unit  performing  the 

assault. 


B  The  automatic  event  description  (FILE12  array)  defined  in 

paragraph  7  of  Appendix  B  to  this  chapter. 

C  The  velocity  of  the  escort  and  transport  aircraft  respectively, 

in  knots,  followed  by  the  limiting  velocity  in  meters  per 
centiminute. 


6.  ROUTINE  ASULT2.  A  sample  of  the  printed  output  from  routine  ASULT2  is 
presented  in  Figure  IV-15-C-4.  Each  print  group  is  identified  by  an  alpha¬ 
betic  descriptor  as  explained  below.  All  output  is  keyed  to  print  switch  2. 

Output 

Descriptor  Explanation 

A  The  automatic  event  description  (FILE12  array)  defined  in 

paragraph  7  of  Appendix  B  to  this  chapter. 

B  Airmobile  mix  table  defined  in  paragraph  4  of  Appendix  B  to 

this  chapter. 

C  200-character  array.  The  locations  of  "M"  entries  in  the  list 

identifying  item  codes  of  equipment  exempt  from  the  weight 
and  volume  limitation. 

D  The  first  column  of  this  table  contains  weights  and  the  second 

column  contains  volumes. 


9 
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Output 

Descriptor 


Explanation 


If  entire  unit  can  be  lifted: 

Row  1  -  unused 

Row  2  -  lift  capacity 

Row  3  -  unit  requirement 

If  the  entire  unit  cannot  be  lifted: 
Row  1  -  unit  requirement 
Row  2  -  unused  lift  capacity 
Row  3  -  load  remaining 


7.  ROUTINE  ASULT3.  A  sample  of  the  printed  output  from  routine  ASULT3  is 
presented  in  Figure  IV-15-C-5.  Each  print  group  is  identified  by  an  alpha¬ 
betic  descriptor  and  explained  below.  All  output  is  keyed  to  print  switch  2. 


Output 

Descriptor  Explanation 

A  The  automatic  event  descriptor  (FILE12  array)  defined  in 

paragraph  7  of  Appendix  B  to  this  chapter. 

B  The  first  entry  is  the  distance  flown  on  previous  flight  leg. 

The  second  entry  is  the  time  required  for  previous  flight 
leg.  If  a  refuel  decision  was  made,  the  second  entry  is  the 
time  the  unit  can  fly  with  the  fuel  currently  on  board  and 
the  third  entry  is  the  length  of  time  required  to  fly  one 
complete  round  trip. 


8.  ROUTINE  ASULT4.  The  output  from  routine  ASULT4  is  only  the  automatic 
event  description  (FILE12  array)  described  in  paragraph  7  of  Appendix  B  to 
this  chapter. 


9.  ROUTINE  RLEAS1.  A  sample  of  the  printed  output  from  routine  RLEAS1  is 
presented  in  Figure  IV-15-C-6.  Each  print  group  is  identified  by  an  alpha¬ 
betic  descriptor  and  explained  below.  Descriptor  B  and  D  are  keyed  to  print 
switch  2. 

Output 

Descriptor  Explanation 

A  The  weather  condition  code  (0-3) .  This  value  is  printed  by 

routine  WETTHR. 

B  The  transport  and  escort  fuel  consumption  rates  in  gallons  per 

hour  from  data  file  14. 


C  Output  from  routine  PENRAT,  described  previously. 

D  Automatic  event  description  (FILE12  array).  The  array  contains 

the  information  which  follows. 


J 


* 


J 

<r 
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Figure  IV-15-C-6.  Sample  Printed  Output  from  Routine  RLEAS1 


Word 


Content 


1  Operation  code. 

2  Unit  releasing  aircraft 

3,  4,  and  5  Mission  unit  identifications 

6  Penetration  flag  (0  =  no,  1  =■  yes) 

7  Fuel  consumed  during  next  flight  leg 

11  Force  (1  *  Blue,  2  =  Red) 

12  Transport  aircraft  item  code 

35  In-flight  attrition  return  code 

10.  ROUTINE  RLEAS2.  A  sample  of  the  printed  output  from  routine  RLEAS2  is 
presented  in  Figure  IV-15-C-7.  Each  print  group  is  identified  by  an  alpha¬ 
betic  descriptor  and  explained  below.  All  output  is  keyed  to  print  switch  2 . 


Output 

Descriptor  Explanation 

A  The  time  required  to  fly  from  the  safe  point  to  each  airbase 

in  centiminutes. 

B  Automatic  event  description  (FILE12  array)  defined  in  preceding 

paragraph. 

11.  ROUTINE  RLEAS3.  A  sample  of  the  printed  output  from  routine  RLEAS3  is 
presented  in  Figure  IV-15-C-8.  Each  print  group  is  identified  by  an  alpha¬ 
betic  descriptor  and  explained  below.  Descriptors  A  and  D  are  keyed  to  print 
switch  2. 


Output 

Descriptor 


Explanation 

The  number  of  B-,  C-,  and  D-  kills  suffered  by  transport  and 
escort  aircraft. 

Aircraft  landing  times  from  data  file  26  in  centiminutes  for 
transport  and  escort  aircraft. 

Time  to  restore  undamaged  transport  and  escort  aircraft  to 
service  in  centiminutes. 

Automatic  event  description  (FILE12  array),  described  previously. 


Not  shown  Times  to  restore  damaged  aircraft  may  appear  between  descriptors 

B  and  C. 
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Figure  IV-15-C-7.  Sample  Printed  Output  from  Routine  RLEAS2 
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Figure  IV-15-C-8. 


Sample  '  ’-tad  afcput  from  Routine  RLEAS3 
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12.  ROUTINE  RLEAS4.  A  sample  of  the  printed  output  from  routine  RLEAS4  is 
shown  below.  This  print  identifies  the  airbase,  the  item  code  of  the  aircraft 
being  restored,  and  the  number  of  aircraft.  It  is  keyed  to  print  switch  2. 

'•LLEASC4 
I  0  I  DAB  -  19b 

lACtCH  "  An 

4  0  'J  Ni  T  -  s.cc:cc 

13 .  REARM/REFUEL  SUBMODEL.  The  printout  shown  in  Figure  IV-15-C-9  is  output 
from  the  Rearm/Refuel  submodel  of  the  Airmobile  Model.  This  submodel  simulates 
the  rearming  and  refueling  of  aircraft  flights  using  the  restraints  of  time 
and  resources  input  to  it. 

Output 

Descriptor  Explanation 

A  TCLOCK  =  Current  game  time  in  centiminutes . 

FRRA  IOPR  =  Numerical  code  indicating  rearm/refuel  status  of 
flight  and  which  routine  is  to  be  called  to  further  process 
the  flight. 

MUID  =»  IUID  of  the  mission  unit. 

MUID4  =  IUID  of  the  assault  unit. 

B  DMX  -  Distance  from  mission  unit  to  resupply  point. 

C  IUIDMU  =*  IUID  of  mission  unit. 

COCUID  -  IUID  of  forward  rearm/refuel  area  (FRRA). 

IRRUTD  *■  List  of  UTDs  of  possible  FRRAs . 

D  INDX  =  Index  indicating  the  UTD  of  the  FRRA  selected. 

IREC24  =  Number  of  the  record  on  data  file  24  assigned  to  this 
unit 

IOPR  =  See  FRRA  IOPR  description,  descriptor  A. 

E  PRSRAP  =  Present  number  of  rearm  points  (-RAC  *  present  strength/ 

authorized  strength) 

PRSRFP  =*  Present  number  of  refuel  points  (II  number  of  refuel 
points  per  vehicle  *  number  of  vehicles  on  hand) 

RAC  -  Rearm  capacity  of  FRRA  if  it  has  100  percent  personnel 
strength. 

RFC  ■  Refuel  capacity  of  FRRA  if  it  has  100  percent  vehicles 
authorized. 

DELT  ■  Time  required  for  the  mission  unit  to  reach  the  FRRA 
chosen. 

F  IUIDMU  ■  List  of  the  IUIDs  of  mission  units  being  processed  or 

to  be  processed  at  this  FRRA. 

TIF  *  List  of  the  total  number  of  inlets  to  be  refueled  in  each 
mission  unit. 

TACRA  ■  List  of  the  total  number  of  aircraft  to  be  rearmed  in 
each  mission  unit. 
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TCLOCK=  xxxx,  FRRA  IOPR®  xxx  MUID=  xxx 
DMX=  xxx 

IUIDMU®  xxx  COCUID=  xxx 
IRRUTD=  AAAA  AAAA  . . . 

INDX®  xxx  IREC24®  xxx  IOPR®  xxx 

PRSRAP  =  xxx  PRSRFP  =  xxx  RAC  =  xxx  RFC 


MUID4®  xxxx 


=  xxx  DELT  =  xxx 


®— 


"IUIDMU= 

XXX 

xxx 

xxx 

xxx 

xxx 

xxx 

TIF= 

xxx 

xxx 

xxx 

xxx 

xxx 

xxx 

TACRA= 

xxx 

xxx 

xxx 

xxx 

xxx 

xxx 

READY® 

xxx 

xxx 

xxx 

xxx 

xxx 

xxx 

TAC= 

xxx 

xxx 

xxx 

xxx 

xxx 

xxx 

RFTPI® 

xxx 

xxx 

xxx 

xxx 

xxx 

xxx 

RADAT® 

xxx 

xxx 

xxx 

xxx 

RACAA® 

xxx 

xxx 

xxx 

RFC  »  xxx 

RAC 

=  xxx 

QI  =  xxx  RFP  =  xxx 

©  - IA  =  xxx  IS  =  xxx  ICR  *  xxx  DELT  =  xxx 

® -  IRB  =  xxx  IWD  =  xxx  MIXTAB  =  xxx  xxx  xxx 


RAP  =  xxx 
CLASS3A®  xxx 


0 — ! 
© — 

© — 
©- 
©— 


xxx  TIF  *  xxx  EOH  *  xxxx 

x  TAV  *  xxx  RFC 
xxx 

xxx  AIRSPD  ®  xxx  K 


RAP  «  xxx 

QI  -  x: 

IDT  -  xxx 

ACBP  = 

•IOPR  »  xxx 

ALT  -  : 

IOPR  -  xxx 

IUIDMU 

FCOMP  -  xxx 

ACOPM 

IV-15-C-9 . 

Sample 

xxx 


xxx  EOH  »  xxx  CONSUM  ®  xxx 


xxx  RA  TIME  POINTER  -  xxx  NABP  -  xxx  RETX  »  xxx 

RETY  ■  xxx  RET  IOPR  =  xxx 


Next  Page) 
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© —  RRQUE  -  xxx  xxx  xxx  xxx  xxx  xxx  xxx  xxx 

©—  RRQUE  -  xx .  xx .  xx .  xx .  xx .  xx . 

® —  MUID  =  xxx  CUID  ■  xxx  QI  *  xxx  RFC  =  xxx  RAC  -  xxx  RFP  *  xxx  RAP  =  xxx 

|  SN  =  xxx  xxx  xxx  .... 

(R) - J  IC  =  xxx  xxx  xxx 

I _ TOTRFP  =•  xxx  RFC  *  xxx  ACBP  3  xxx  COPRSRFP=  xxx 


-IOPR  =  xxx  IDT  =*  xxx 


Figure  IV-15-C-9.  Sample  Printed  Output  from  Rearm/Refuel  (Concluded) 


Output 

Descriptor 

F 


G 


H 


Explanation 

READY  »  List  of  the  number  of  aircraft  which  have  been  refueled 
and  are  ready  to  be  rearmed  in  each  mission  unit. 

TAC  List  of  the  times  required  to  arm  one  aircraft  in  each 
mission  unit. 

RFTPI  =  List  of  the  times  required  to  refuel  one  fuel  inlet  in 
each  mission  unit. 

RACAT  =  List  of  times  rearm  capacity  will  become  available. 

RACAA  ■  List  of  the  amounts  of  rearm  capacity  that  will  become 
available  at  the  times  listed  under  RACAT  above. 

RFC  ■  See  descriptor  E. 

RAC  »  See  descriptor  E. 

QI  =  Pointer  to  the  last  position  being  used  in  the  20-position 
queue  of  the  FRRA. 

RFP  =  Pointer  to  the  position  in  the  queue  of  the  mission  unit 
currently  being  refueled. 

RAP  -  Pointer  to  the  position  in  the  queue  of  the  mission  unit 
currently  being  rearmed. 

IA  “  Altitude  cut-off  indicator. 

IS  *  Air  speed  cut-off  indicator. 

ICR  *  Pointer  to  consumption  rate  selected. 

DELT  3  Time  required  by  mission  unit  to  fly  to  FRRA. 

CLASS3A  »  Amount  of  fuel  consumed  en  route  to  FRRA. 

IRB  ■  Force  indicator  (1  «  Blue,  2  *  Red). 

IWD  «  Pointer  to  the  first  word  of  the  mix  table  selected. 

MIXTAB  *  Mix  table  describing  the  composition  of  the  mission 
unit.  A  description  of  each  word  follows. 

Word  Content 


1 

Escort 

aircraft 

item  code 

2 

Escort 

aircraft 

personnel 

3 

Escort 

aircraft 

fuel  capacity 

4 

Escort 

aircraft 

munition 

type 

1 

item  code 

5 

Escort 

aircraft 

munition 

type 

1 

amount 

6 

Escort 

aircraft 

munition 

type 

2 

item  code 

7 

Escort 

aircraft 

munition 

type 

2 

amount 

8 

Escort 

aircraft 

munition 

type 

3 

item  code 

9 

Escort 

aircraft 

munition 

type 

3 

amount 

10  Transport  aircraft  item  code 
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Word 

Content 

11 

Transport  aircraft  personnel 

12 

Transport  aircraft  fuel  capacity 

13 

Escort  aircraft  rearm  time 

14 

Escort  aircraft  fuel  inlets 

15 

Transport  aircraft  fuel  inlets 

Output 

Descriptor  Explanation 

I  K  *  Aircraft  item  code* 

TIF  =  Number  of  inlets  to  be  refueled  in  this  mission  unit. 

EOH  =  Number  of  aircraft  in  this  mission  unit. 

J  RAP  =  See  descriptor  F. 

QI  »  See  descriptor  F. 

TAV  »  Time  next  rearm  capacity  will  be  available. 

RFC  *  See  descriptor  E. 

K  IDT  »  Time  required  to  refuel  these  aircraft. 

ACBP  -  Number  of  aircraft  inlets  being  refueled. 

L  IOPR  -  See  FRRA  IOPR,  descriptor  A. 

ALT  ■  See  UMAIN  description,  Chapter  2  to  Section  VII. 

AIRSPD  *  See  UMAIN  description.  Chapter  2  to  Section  VII. 

K  «  Item  code  of  aircraft. 

EOH  =  Number  of  aircraft. 

CONSUM  »  Fuel  consumed  by  mission  unit  en  route  to  FRRA, 

M  IOPR  -  See  FRRA  IOPR  descriptor  A. 

IUIDMU  =*  IUID  of  mission  unit. 

RA  Time  Pointer  -  Pointer  to  entry  in  RADAT  and  RACAA  arrays 
for  this  unit. 

NABP  *  Number  of  aircraft  being  processed  at  this  time. 

RETX,  RETY  «  Coordinates  of  location  that  mission  unit  is  to 
return  to  when  rearming  and  returning  are  complete. 

RET  IOPR  *  Numerical  code  indicating  the  operation  that  the 
unit  is  to  engage  in  when  rearming  and  refueling  are  complete 

N  FCOMP  ■  Number  of  inlets  remaining  to  be  refueled  in  the 

mission  unit. 

ACOMP  *  Number  of  aircraft  remaining  to  be  rearmed  in  the 
mission  unit. 

0  RRQUE  - 

QI  ■  See  descriptor  F. 

RFP  ■  See  descriptor  F. 
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Output 

Descriptor 


P 


Q 


R 


S 


Explanation 


RAP  =  See  descriptor  F. 

IOPR  =  See  descriptor  A,  FRRA  IOPR. 

TCLOCK  =  Current  game  time. 

NTIME  *  Time  mission  unit  begins  waiting  in  FRRA  queue. 

TAV  =  Time  mission  unit  can  begin  refueling. 

DELT  =  Time  unit  must  wait  "o  enter  queue. 

RRQUE  = 

RFC  =  See  descriptor  E. 

RAC  =  See  descriptor  E. 

FRQ  *  Fuel  required  by  unit. 

CLAS3A  =*  Amount  of  fuel  on  hand  in  unit. 

TIF(QI)  =  Total  inlets  to  be  refueled  in  this  unit. 
RFTPI(QI)  a  Time  required  to  refuel  one  inlet  in  this  unit. 

MUID  =  DID  of  mission  unit. 

CUID  -  UID  of  FRRA. 

QI  =  See  descriptor  F. 

RFC  »  See  descriptor  E. 

RAC  =  See  descriptor  E. 

RFP  =  See  descriptor  F. 

RAP  =  See  descriptor  F. 

NN  -  List  of  number  of  nozzles  per  refuel  device  in  FRRA. 

IC  =  List  of  item  codes  of  refuel  devices  in  FRRA. 

TOTRFP  *  Total  refuel  points  in  FRRA  at  this  time. 

RFC  »  See  descriptor  E. 

ACBP  ■  Number  of  aircraft  being  processed. 

COPRSRFP  »  Present  refuel  capacity  of  FRRA. 

IOPR  «*  See  descriptor  A,  FRRA  IOPR. 

IDT  »  Time  which  will  elapse  before  the  next  rearm/refuel 
event  for  this  unit. 


14.  ROUTINE  SIS.  A  sample  of  the  printed  output  from  routine  SIS  is  presented 
in  Figure  IV-15-C-10.  Each  print  group  is  identified  by  an  alphabetic  descrip¬ 
tor  and  explained  below. 

Output 

Descriptor  Explanation 

A  SIS  MSUNT  is  the  IUID  of  the  aircraft.  DISTBE  is  the  total 

distance  of  the  MES  and  MESEND  is  the  end  time  of  the  MES. 

B  1ADCU  is  the  unit  identification  index  of  an  air  defense- 

capable  unit  (ADCU)  and  ITEM  is  the  item  code  of  the  ADCU 
weapon.  QUANT  is  the  amount  of  this  weapon  on  hand.  ADDIST 
is  the  distance  of  this  weapon  from  the  aircraft  and  WEP  RNG 
is  the  range  of  this  particular  weapon. 
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Output 

Descriptor  Explanation 

C  Following  indicator  6901  is  the  distance  of  the  aircraft  from 

the  front  of  the  ADCU  unit  and  the  range  of  this  weapon. 

‘After  indicators  6902  and  6903  the  amount  of  this  weapon  on 
hand  is  printed.  Indicator  6907  licts  the  maximum  lock-on 
boundary  of  a  missile.  After  indicator  6908  the  effective 
slew  rate  required  to  fire  at  the  aircraft  and  the  slew  rate 
of  the  particular  weapon  is  printed. 

D  Format  indicator  6110  contains  the  beginning  X  and  Y  coordinates 

of  a  MES,  the  ending  X  and  Y  coordinates  of  a  MES,  the 
effective  X  and  Y  beginning  intercept,  the  corresponding  SEP 
and  THAD  values  from  PONTLN,  the  effective  ending  X  and  Y 
intercept,  and  the  corresponding  SEP  and  THAD  values  from 
PONTLN. 

E  Format  indicator  6122  shows  whether  or  not  the  weapon  intercept 

points  are  beyond  the  beginning  and  ending  major  engagement 
segment  (MES)  points.  If  both  values  are  1  or  both  values 
are  2,  the  intercepts  are  both  off  of  the  same  end  of  the  MES 
and  both  coordinates  are  dropped;  however,  if  the  values  are 
not  the  same,  the  points  straddle  the  MES  and  they  are 
retained.  The  beginning  and  ending  firing  times  follow 
format  indicator  6123.  If  the  value  following  format  indi¬ 
cator  6150  is  greater  than  zero,  the  delays  are  skipped.  The 
effective  beginning  and  ending  firing  times  follow  indicator 
6350. 

F  Array  TEMPI  contains  the  IUID  of  an  ADCU  in  the  first  position, 

the  weapon  item  code  in  the  second,  the  firing  time  in  the 
third,  and  a  flag  indicating  beginning  (1)  or  ending  (2) 
firing  time  in  the  fourth  position. 

G  TEMPI  contains  the  same  values  as  explained  for  descriptor  F 

except  that  the  array  has  been  ranked  by  the  firing  times. 

H  The  value  following  indicator  6625  is  a  counter  in  a  loop  on 

array  TEMP2.  Format  indicator  6630  is  written  to  show  that 
there  were  not  any  values  greater  than  zero  in  the  first 
position  of  array  TEMP2. 

I  Following  IREC  is  the  value  of  the  record  pointer  and  the  values 

of  array  ISREC.  Indicator  6460  contains  the  first  two  entries 
in  array  TEMP2  and  the  value  of  IC0UNT.  Indicator  6501  is 
written  to  show  this  is  a  later  time  event  and  a  check  is 
being  made  to  find  the  counterpart.  The  value  of  K  (loop 
counter),  the  record  pointer,  and  the  array  ISREC  follow 
indicator  6640. 

J  The  values  contained  in  array  FILE12  are  listed. 
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Output 

Descriptor  Explanation 

K  Indicator  6470  contains  the  value  of  a  loop  counter  which 

compares  the  contents  of  array  TEMPI  and  TEMP2.  Indicator 
6490  contains  the  values  of  TEMP2. 


L  The  values  contained  in  array  FILE12  are  listed. 

Not  Shown  The  first  intercept  time  is  before  the  MES  start  if  indicator 

6130  is  written.  The  beginning  intercept  is  set  to  the  MES 
start  time.  Statement  6130  contains  the  MES  start  and  end 
times. 

Indicator  6140  is  the  same  as  6130  except  that  the  end  time  was 
greater  than  the  MES  end  time.  The  delay  time  follows  indi¬ 
cator  6151  if  it  exists.  Indicator  6700  contains  the  MES  end 
time  if  no  intercept  segment  was  found. 

15.  ROUTINE  GTAA: 


a.  A  sample  of  the  printed  output  from  routine  GTAA  is  presented  in  Figure 
IV-15-C-11.  Each  print  group  is  identified  by  an  alphabetical  descriptor  and 
explained  below. 


Output 

Descriptor 


Explanation 


A  GTAA  indicates  routine  GTAA  has  been  entered. 


B  The  list  following  GTAA  8000  contains  the  X  and  Y  values  of 

the  beginning  coordinates  of  a  major  engagement  segment  (MES), 

X  and  Y  ending  coordinates  of  a  MES,  IOPER,  IUID  of  the 
mission  unit,  time  of  last  assessment,  record  pointer,  pointer 
to  weapon  array  on  data  file  7,  intercept  segment  start  and 
end  time,  MES  distance,  MES  elapsed  time,  beginning  X  and  Y 
intercept  coordinates,  ending  X  and  Y  intercept  coordinates, 
fraction  of  time  of  MES  between  MES  start  and  intercept  start, 
and  the  fraction  of  time  of  MES  between  MES  start  and  intercept 
end. 


C  Format  indicator  8099  lists  the  IUIDs  of  the  ADCUs  detected. 

D  Indicator  8105  contains  the  fraction  of  suppression  time 

(FRACSU)  and  the  suppression  flag.  Following  indicator  8150 
are  the  values  of  the  X,  Y,  and  Z  coordinates  of  the  mid  point 
of  the  intercept  segment,  the  distance  of  the  aircraft  from 
the  mid  point  of  the  intercept  segment,  distance  of  the  base, 
the  sine  of  the  horizontal  angle,  the  altitude  of  the  ADCU, 
the  slant  range,  the  sine  of  the  vertical  angle,  the  cosine 
of  the  horizontal  angle,  the  horizontal  slew  rate,  the  vertical 
slew  rate,  the  distance  of  the  ADCU,  the  direction  of  the 
flight,  and  the  cosine  of  the  vertical  angle. 
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Output 

Descriptor 


E 

F 


G 


H 


I 


J 

K 


Explanation 

Following  statement  indicator  2234  is  an  aircraft  equipment 
item  code  and  a  listing  of  array  ACDATA. 

Indicator  8160  contains  the  loop  counter,  the  ACDATA  subscript, 
amount  of  aircraft  type  1,  amount  of  aircraft  type  2,  bottom 
presented  area,  side  presented  area,  front  and  rear  presented 
area,  presented  area  for  type  J,  average  evasive  maneuver  turn 
rate,  aircraft  type  (rotary  or  fixed  wing),  and  the  equipment 
item  code.  Indicator  8180  is  followed  by  the  roughness  and 
vegetation  index,  the  forestation  factor,  the  target  of  the 
vertical  angle,  the  vertical  angle,  and  the  fraction  of  line  of 
sight.  8185  contains  the  resultant  fraction  of  line  of  sight. 

The  list  following  8200  contains  the  record  pointer,  the  weapon 
item  code,  and  the  amount  of  weapons  on  hand.  Following  8220 
are  the  values  of  the  air  defense  weapon  type,  the  aircraft 
type,  the  record  pointer,  the  horizontal  slew  rate  of  the 
weapon,  and  the  vertical  slew  rate  of  the  weapon.  8230  is 
followed  by  the  visibility  index,  the  index  value,  the 
visibility  degradation,  the  eight  variables  passed  to  routine 
CIRCLE,  and  the  fraction  of  the  ADCU  weapons  within  range. 

8240  is  followed  by  the  fraction  of  the  unit's  fatalities,  the 
fraction  of  the  unit  suppressed,  the  reliability  factor,  and 
the  array  ECMF.  8250  contains  the  loop  counter,  weapon  flag, 
and  number  of  weapons  on  hand  at  last  inventory  for  this 
ACDU . 

The  values  following  format  indicator  8601  are  the  slant  range, 
average  miss  distance  for  a  missile  in  mils,  equipment  item 
code,  amount  of  equipment  type  1,  amount  of  equipment  type  2, 
amount  of  equipment  on  hand  for  this  type  of  aircraft,  average 
miss  distance,  one  sigma  error,  presented  area  (1),  presented 
area  (2) ,  several  intermediate  calculations  used  to  find  the 
miss  distance,  and  the  miss  distance.  8612  contains  a  record 
pointer,  weapon  flag,  number  of  words  for  a  GETWRD,  and  the 
maximum  miss  distance. 

Format  indicator  8615  gives  a  list  of  probabilities  at  equal 
intervals. 

The  first  value  following  indicator  8620  is  the  magnitude  of 
the  steps  in  the  preceding  probability  and  the  second  value 
is  the  resultant  probability.  Indicator  8650  contains  the 
amount  of  the  weapon  fired  and  the  probability  of  a  kill  for 
a  missile  array. 


b.  Additional  printed  output  not  present  in  the  example  are  described 
below. 
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(1)  Indicator  8103  contains  the  IUID  of  the  ADCU,  the  intercept 
segment  start  time,  the  intercept  segment  end  time,  start  time  for  the  TACAIR/ 
ground-based  artillery  suppression,  and  the  end  time  for  the  same  suppression. 
Indicator  8104  contains  the  suppression  flag  followed  by  the  intercept  segment 
start  and  end  times,  and  the  effective  artillery  suppression  times.  Indicator 
8110  contains  intermediate  calculations  used  to  determine  whether  the  aircraft 
is  past  the  no  request  point.  8111  is  followed  by  the  start  and  end  times  for 
an  escort  suppression  and  the  aircraft  type. 

(2)  Indicator  8125  is  followed  by  the  amount  of  escort  aircraft  on 
hand.  Indicator  8300  contains  the  average  fire  rate  without  reloading,  time 
to  exhaust  the  magazine  capacity,  reload  delay  time,  number  of  reloads, 
effective  firing  time,  and  the  number  of  rounds  fired.  8351  lists  the  amount 
of  ammunition  on  hand,  the  number  of  rounds  fired,  and  the  number  of  rounds 
fired  per  aircraft.  8360  lists  the  slant  range,  the  drag  coefficient,  the 
muzzle  velocity,  the  time  of  flight  for  the  projectile,  the  directional 
factor,  the  striking  velocity,  and  the  vulnerable  area  array. 

(3)  Format  indicator  8400  is  followed  by  the  aircraft  speed  in  meters, 
the  target  angular  rate  from  the  ADCU,  the  slant  range  adjusted  for  use  with 
mils,  the  average  aircraft  turn  acceleration  in  meters  per  second,  and  the 
ballistic,  aiming,  and  target  maneuver  error.  8410  is  followed  by  intermediate 
calculations  used  to  calculate  the  total  ballistic,  aiming,  and  target  maneuver 
errors  for  case  A  (standard  deviation  in  meters  squared) .  Indicators  8420  and 
8421  contain  the  same  information  for  case  B.  8430  is  for  case  C  and  8440  is 
for  case  D.  8500  is  followed  by  the  number  of  weapons  on  hand  for  this  type, 
two  loop  counters,  and  the  amount  of  aircraft  on  hand  for  escorts  and  for 
transports.  8501  contains  the  probability  of  a  hit  by  one  round,  the  number 

of  weapons  on  hand,  two  loop  counters,  two  index  values,  the  vulnerable  area, 
the  presented  area,  the  probability  of  a  kill  for  one  round,  the  number  of 
rounds,  the  probability  of  a  kill  for  n  rounds,  and  the  probability  of  the 
aircraft's  survival. 


(4)  Indicators  9045,  9046,  9047,  and  9048  contain  the  joint 
suppression  interval. 

16.  ROUTINE  LOSSES.  A  sample  of  the  printed  output  from  this  routine  is 
presented  in  Figure  IV-15-C-12.  Each  print  group  is  identified  by  an  alpha¬ 
betical  descriptor  and  explained  as  follows. 


Output 

Descriptor 


Explanation 


A  Following  the  format  indicator  8701  is  the  value  of  the  amount 

of  aircraft  on  hand. 


B  The  value  following  format  indicator  8703  is  the  amount  of 

aircraft  remaining.  Indicator  8706  contains  the  aircraft 
item  code  and  the  amount  of  aircraft  now  on  hand. 

C  Format  indicator  8708  is  written  for  each  type  of  kill  (A,  B, 

C,  and  D) .  The  values  written  are  the  loss  to  missiles,  the 
loss  to  guns,  casualties,  aircraft  type  indicator,  and  the 
type  of  kill. 
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gure  IV-15-C-12.  Sample  Printed  Output  from  Routine  LOSSES 


Output 

Descriptor 

D 


Explanation 


XACT  and  YACT  are  the  unit's  location  when  the  unit  leaves 
GTAA  on  this  flight  leg. 

17.  ROUTINE  MES.  The  printed  output  of  routine  MES  is  shown  in  the  example 
of  Figure  IV-15-C-13.  An  alphabetical  descriptor  identifies  each  print  group 
which  is  explained  below. 


Output 

Descriptor 


Explanation 


A  The  values  of  array  FILE12  as  they  are  passed  to  routine  MES 

are  listed. 


B  The  first  three  values  are  the  unit's  present  location  (XACT, 

YACT,  and  ZACT) .  The  second  three  values  are  the  coordinates 
where  the  unit  is  being  moved  (MEVTX,  METVY ,  MEVTZ) . 

C  A  list  of  the  air  defense  weapon  item  codes  is  given. 

D  The  values  following  the  statement  indicator  6904  are  the 

weapon's  night  capability  code  (NITCAP) ,  the  weapon's 
weather  capability  code  (NWECAP) ,  and  the  weather  code  for 
this  location.  Following  statement  indicator  6905  are  the 
weapon's  maximum  and  minimum  altitude  and  the  altitude  of 
the  aircraft.  Following  statement  indicator  6906  are  the 
maximum  and  minimum  speed  of  the  weapon  and  the  airspeed  of 
the  aircraft. 


E  This  is  a  list  of  the  air  defense  weapon  item  codes  that  are 

capable  of  intercepting  the  aircraft.  F' l lowing  is  a  list 
of  the  ranges  of  the  corresponding  ait  defense  weapons. 

F  DELF  is  the  accumulated  distance  flown.  RL00K  is  the  radius  of 

the  search  area  at  this  look  point.  Following  NEW  COORDS  is 
the  unit's  actual  location  for  this  look  point  (XA,  YA,  and 
ZA) . 

G  Following  UNIT  is  the  IUID  of  the  air  defense  capability  unit 

(ADCU) .  D1ST1  is  the  distance  of  the  ADCU  from  the  aircraft 
and  JSWCH  is  the  status  of  the  flight  leg. 

H  13  is  the  number  of  units  in  LIST3  and  14  is  the  number  of 

units  in  LIST4 .  LIST3  and  LIST4  contain  IUIDs  of  ADCUs. 


I  I0PER  is  the  event  code  of  the  automatic  event  created  in  MES. 
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CHAPTER  16 

C0M3AT  SERVICE  SUPPORT  MODEL 


1.  MILITARY  ACTIONS  REPRESENTED: 

a.  General.  Personnel,  major  end  items,  and  combat  essential 
material  must  be  replaced  within  a  military  unit  when  required.  If 
the  unit  does  not  have  a  ready  source  of  personnel  and  materiel, 
the  capability  of  the  unit  to  accomplish  its  mission  is  severely 
limited.  The  DIWAG  Combat  Service  Support  (CSS)  Model  simulates 
personnel  replacement,  resupply  of  critical  consumables  and  ex¬ 
pendables,  and  resupply  of  major  end  items.  The  model  does  not 
simulate  resupply  of  repair  parts.  The  resupply  or  replacement 
process  is  treated  in  three  essential  areas;  requesting,  distributing, 
and  receiving  supplies.  These  aspects  of  resupply  are  simulated 
differently  for  critical  consumables  and  expendables  (classes  III 

and  V)  and  for  personnel,  class  I,  and  major  end  items. 

b.  Resupply  of  Critical  Consumables  and  Expendables: 

(1)  Requesting.  The  process  of  requesting  or  ordering 
supplies  requires  the  determination  of  the  quantity  to  request, 
when  to  request,  and  the  priority  of  the  request. 

(a)  The  quantity  to  request  is  based  on  a  critical 
level  check.  If  the  amount  authorized  of  an  item  is  less  than 
this  critical  quantity,  resupply  request  is  initiated. 

-  (b)  The  priority  of  a  request  is  dictated  by  the  mission 

v  of  the  using  unit.  Mi thin  the  model,  highest  priority  is  assigned 

to  resupply  of  the  front-line  maneuver  units.  Second  highest 
priority  is  assigned  to  all  other  maneuver  units  and  all  artillery 
units.  Third  priorioy  is  to  resupply  points  used  for  (1)  and  (2). 

The  lowest  priority  is  assigned  to  other  units  not  included  in 
the  first  three  priorities. 

(2)  Distribution  of  Supplies.  In  treating  supply  bistri- 

*  bution,  the  distribution  method  or  policy,  routing,  and  treatment 
of  materiel  upon  receipt  must  be  considered. 

(a)  Method  of  Distribution.  The  Army  supply  system 

•  utilizes  two  methods  of  distribution;  unit  distribution  and  supply- 
point  distribution.  Unit  distribution  refers  to  the  delivery  of 
supplies  from  the  supplying  activity  to  the  consuming  unit,  and 
supply  point  distribution  requires  the  consuming  unit  to  pick  up 

( 
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supplies  from  the  supplying  activity  using  its  own  personnel  and 
vehicles.  3oth  methods  of  distribution  are  treated  in  the  Combat 
Service  Support  Model.  If  one  method  of  distribution  is  impossible 
because  of  lack  of  sufficient  transportation  means,  the  model 
automatically  attempts  to  effect  the  supply  action  using  the  other 
method  of  distribution. 

_1.  In  unit  distribution  all  suppli.s  requested 
are  transported  to  the  requesting  unit  on  vehicles  provided  by 
the  supplying  unit.  If  there  are  net  enough  available  supplies, 
the  unfilled  portion  of  the  order  remains  due  until  they  become 
available.  The  order  and  shipping  times  for  unit  distribution 
include  the  times  required  to  place  and  fill  the  order,  load 
the  vehicles,  transport  the  supplies,  and  unload  them  and  make 
the  supplies  available  to  the  using  unit. 

1_.  In  supply  poinc  distribution  the  unit  needing 
supplies  must  provide  its  vehicles  and  send  them  to  the  supply 
point.  Order  and  shipping  times  in  supply  point  distribution 
include  the  times  required  to  move  the  vehicles  to  the  supoly 
point,  load  the  supplies,  and  return  to  the  unit. 

_3.  The  model  attempts  to  airlift  supplies  if 
sufficient  ground  transportation  is  not  available  and  aircraft  are 
available  at  the  supply  unit. 

4.  If  a  unit  is  involved  in  an  airmobile 
operation,  it  is  not  resupplied  until  the  airlift  has  been 
completed.  If  the  unit  is  airlifted  into  hostile  territory, 
resupply  is  effected  only  through  airlift  operations;  otherwise, 
resupply  is  handled  in  the  same  manner  as  described  above. 

(b)  Routing.  Materiel  can  pass  through  a  number  of 
intermediate  holding  or  handling  points  as  it  progresses  from  an 
original  source  of  supply  to  the  ultimate  user.  Within  the  model 
intermediate  and  initial  supply  points  are  treated.  Intermediate 
supply  points  function  similarly  to  the  ultimate  using  unit  insofar 
as  the  process  of  obtaining  supplies  is  concerned;  an  intermediate 
supply  point  has  a  point  of  supply  identified  from  which  it  can 
obtain  the  required  items  by  unit  or  supply  point  distribution, 
based  on  its  critical  supply  level  for  the  item.  An  intermediate 
supply  point  may  temporarily  run  out  of  supplies  if  the  demand 
exceeds  its  on-hand  stocks  and  resupply  capability.  Initial  supply 
points  are  treated  within  the  model  as  being  unlimited  sources  of 
supply.  The  routing  of  supplies  to  a  using  unit  through  interme¬ 
diate  supply  points  or  directly  from  an  initial  supply  point  is 
established  as  part  of  the  force's  task,  organization  through  gamer 
input. 
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(c)  Treatment  Upon  Receipt.  Upon  receipt  of  supplies, 
the  using  unit  generally  holds  the  supplies  in  bulk  until  such 

time  as  it  is  necessary  or  convenient  to  distribute  them  to  the 
ultimate  user.  For  example,  bulk  ammunition  can  be  held  in  the 
combat  trains  of  a  maneuver  unit  for  seme  period  of  time  until 
its  distribution  among  the  weapons  systems  that  fire  the  ammuni¬ 
tion  can  be  effected.  Within  the  model,  every  unit  which  receives 
supplies  is  treated  as  having  a  holding  point  for  bulk  supplies, 
nominally  the  unit  combat  trains.  Supplies  are  delivered  to  the 
trains  and  transferred  from  trains  to  the  unit's  using  entities 
on  a  periodic  basis.  As  currently  programmed  this  process  is 
accomplished  once  every  2  hours.  Artillery  and  air  units  may 
receive  quantities  in  bulk  whenever  needed  on  an  emergency  resupply 
basis;  such  resupply  is  handled  within  the  Area  Fire  and  Air  Ground 
Mode is . 

(d)  Materiel  Flow.  Figure  IV-1&-1  illustrates  the 
basic  flow  of  materiel  from  an  initial  supplier,  to  the  nominal 
trains  of  an  intermediate  supplier,  to  the  intermediate  supplier's 
using  (in  this  case  shipping)  entities  in  the  using  unit.  Zero, 
one,  or  more  than  one  intermediate  suppliers  nay  be  involved.  The 
figure  also  illustrates  the  basic  flow  of  personnel,  major  end  items, 
and  class  I  consumables  in  which  all  nominal  trains  are  bypassed. 

c.  Resupply  of  Personnel,  Major  2nd  Items,  and  Class  I: 

(1)  Resupply  of  Major  End  Items: 

(a)  To  accomplish  the  resupply  of  major  end  items, 
the  pregame  data  load  specifies  by  item  code  which  items  active 

in  the  game  are  treated  as  major  end  items,  the  amount  of  each  item 
available  for  replacement  during  each  24-hour  increment,  and  if 
separate  transport  is  required,  the  equipment  item  to  transport 
each  item  to  be  replaced. 

(b)  To  establish  the  quantity  of  items  available  for 
resupply,  a  multiple  class  supply  point  which  controls  receipt 
and  issue  of  major  items  is  established  within  the  model.  This 
point  contains  all  items  available  for  resupply  where  the  amount 
available  on  a  given  day  is  the  accumulation  of  amounts  specified 
by  input  for  that  and  all  previous  days,  less  the  amount  that  has 
actually  been  sent  to  using  units.  The  basic  assumption  is 

that  limited  stocks  are  available  in  division  maintenance  floats 
and  rear  service  areas.  Initial  stocks  and  daily  replenishment 
quantities  can  be  specified  in  the  constant  data  input. 


( 
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Figure  IV-16-1.  Flow  of  Resupply  Actions  in 
Combat  Service  Support  Model 
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(c)  To  determine  units  receiving  major  items,  a  type  of  daily 
loss  report  which  serves  as  a  requisition  is  developed  for  each  unit  active 
in  the  game.  Units  are  resupplied  within  three  groups  with  first  priority 
to  front-line  maneuver  units,  second  priority  to  other  maneuver  units  and 
artillery  units,  and  third  priority  to  all  other  units.  If  insufficient 
items  are  available  to  meet  all  requirements  within  a  priority  group,  avail¬ 
able  items  are  prorated  according  to  needs.  For  example,  if  unit  A  requires 
10  items  and  unit  B  requires  20  items  and  only  15  are  available,  unit  A  will 
receive  5  items  and  unit  B  will  receive  10  items.  An  item  will  move  from 
the  supply  point  to  the  receiving  unit  at  the  road  movement  rate  of  the 
item,  if  self-transportable,  or  of  the  transporter,  if  not  self-transportable. 

(2)  Resupply  of  Class  I: 

(a)  Class  1  supplies  are  items  consumed  at  a  uniform  and 
predictable  rate,  irrespective  of  combat  or  terrain  conditions,  and  require 
no  adaptation  to  individual  requirements  (FM  17-1,  Reference  1).  Within  the 
model  class  I  supplies  consist  of  rations.  In  the  division,  a  formal  requisi¬ 
tion  for  class  I  supplies  is  not  required.  The  division  supply  and  transport 
battalion  requests  rations  for  the  division,  based  on  estimated  strength  fig¬ 
ures  provided  by  the  adjutant  general,  72  hours  before  the  time  rations  are  to 
be  delivered.  Upon  receipt,  rations  are  broken  down  into  battalion  and  sepa¬ 
rate  unit  lots  based  on  personnel  daily  summaries  submitted  by  each  unit.  In 
rapidly  changing  situations,  it  may  be  necessary  for  units  to  submit  daily 
informal  requisitions  for  the  number  of  rations  required.  These  requisitions 
compensate  for  cross  attachments  and  casualties. 

(b)  In  the  model  class  I  is  resupplied  daily.  It  is  assumed 
that  units  submit  daily  informal  requests  for  number  of  rations  required. 
Requisitions  compensate  for  cross  attachments  and  casualties.  The  resupply 
level  of  a  unit  is  based  on  the  number  of  personnel  attached  to  the  unit  at 
the  time  resupply  is  to  occur.  This  time  is  fixed  within  the  model.  Once 
the  number  of  personnel  in  a  unit  is  determined,  the  resupply  quantity  is 
calculated  on  a  pounds-per-man-per-day  basis.  The  class  I  consumables  are 
delivered  directly  to  the  using  units. 

(c)  The  main  purpose  for  modeling  class  I  resupply  is  to  con¬ 
strain  the  transportation  available  to  resupply  other  commodities,  primarily 
ammunition  and  fuel.  It  is  assumed  that  battalions  and  separate  units  use 
organic  transportation  to  pick  up  rations  at  the  division  class  I  distribution 
point  in  the  brigade  trains  area.  If  all  food  ordered  cannot  be  delivered  at 
the  first  attempt,  the  unfilled  orders  remain,  due  to  be  filled.  At  each  suc¬ 
ceeding  update  attempts  are  again  made  to  fill  the  remaining  class  I  orders. 

No  new  class  I  orders  are  generated  for  24  hours,  but  the  unfilled  orders 

are  retained  until  filled.  Unlike  class  I,  all  other  consumables  that  cannot 
be  delivered  as  scheduled  have  new  backorders  created  at  each  update. 
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(3)  Personnel  Replacement: 


(a)  All  requested  personnel  replacements  received  by  the  division 
are  processed  by  the  replacement  detachment,  which  is  under  the  control  and 
supervision  of  the  adjutant  general.  The  normal  capacity  of  the  detachment 

is  300  replacements  at  one  time  and  can  be  increased  if  additional  control 
personnel  and  equipment  are  provided. 

(b)  Replacements  are  assigned  to  the  division  on  the  basis  of 
daily  replacement  status  reports  submitted  to  higher  headquarters  by  the 
division  adjutant  general.  These  reports  are  based  upon  TOE  position  vacan¬ 
cies  as  shown  in  unit  morning  reports.  Replacements  are  provided  from  per¬ 
sonnel  arriving  from  the  zone  of  interior,  hospital  returnees,  personnel 
being  rotated  from  other  areas,  and  casualties  being  returned  to  duty  from 
various  sources.  Replacements,  even  in  combat,  are  obtained  through  formal 
requisitioning  procedures.  Replacement  personnel  are  requisitioned  to 
replace  actual  losses  in  TOE  positions  only.  Replacements  cannot  be 
requisitioned  for  a  unit  in  advance  of  its  needs. 

(c)  Personnel  requisitions  are  modeled  as  follows: 

JL.  Company  commanders  do  not  requisition  personnel  replace¬ 
ments;  however,  they  do  submit  morning  reports  or  feeder  morning  reports, 
showing  company  personnel  losses,  through  battalion  to  division.  The  company 
commanders  receive,  orient,  and  assign  personnel  replacements  upon  arrival  at 
the  company. 


_2.  The  battalion  SI  does  not  requisition  personnel  replace¬ 
ments.  He  monitors  the  morning  reports  or  feeder  morning  reports  of  the  sub¬ 
ordinate  units  to  ascertain  that  the  units  have  included  known  losses  on  the 
reports . 


^3.  Upon  notification  that  personnel  replacements  are  avail¬ 
able,  the  battalion  SI  coordinates  directly  with  the  S3  and  appropriate  spe¬ 
cial  Staff  Officers  to  determine  battalion  priorities  and  then  informs  the 
division  AG  of  the  priority  of  assignment  to  the  companies.  The  AG  publishes 
division  special  orders  assigning  the  individual  to  his  company  directly  from 
the  division  replacement  company. 

(d)  Within  the  model  personnel  replacement  occurs  once  each  day 
at  a  predetermined  hour.  Time  of  replacement  is  fixed  in  the  model.  The  num¬ 
ber  of  personnel  replaced  is  based  on  two  factors,  type  of  unit  and  current 
strength  of  a  unit.  Data  are  input  to  specify  number  of  replacement  personnel 
available  during  each  24  hours  of  game  play.  If  sufficient  personnel  are  not 
available  to  bring  all  units  up  to  their  authorized  levels,  the  priority  of 
replacement  is  front-line  maneuver  units,  artillery  and  other  maneuver  units, 
and  all  other  units.  Within  priority  groups,  available  replacements  are  evenly 
prorated  according  to  a  unit's  losses.  Personnel  are  resupplied  directly  to 
the  using  unit.  Within  the  model,  no  attempt  is  made  to  replace  personnel  by 
grade  or  military  occupation  specialty. 


» 


) 


l 
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(e)  Replacement  of  personnel  follows  the  logic  developed  for 
resupply  of  principal  items.  Personnel  are  only  requested  once  per  day 
based  on  combat  losses. 

2.  MODEL  DESIGN: 

a.  Model  Logic.  The  basic  logical  flow  of  the  Combat  Service  Support 
Model  is  shown  in  Figure  IV-16-2.  The  sequence  of  processing  groups  of  units 
shown  in  the  figure  imposes  a  priority  on  the  units  to  be  serviced.  In 
resupplying  critical  consumables  and  expendables,  transportation  resources 
available  to  both  the  supplying  and  receiving  units  are  used  in  allocating 
transport.  Thus,  by  the  time  the  second  and  third  groups  of  units  are  pro¬ 
cessed,  transportation  organic  to  the  supply  point  may  have  already  been 
allocated  to  service  higher  priority  units.  In  the  case  of  personnel  and 
major  end  items  only  a  limited  number  of  replacements  is  available.  Resources 
are  allocated  with  first  priority  to  front-line  maneuver  units,  second  pri¬ 
ority  to  other  maneuver  units  and  artillery  units,  and  third  priority  to  all 
remaining  units.  The  dynamic  data  files  and  the  significant  model  steps 

used  in  the  model  logic  are  identified  below  and  discussed  in  detail  in 
paragraph  3. 

b.  Dynamic  Data  Files.  The  Combat  Service  Support  Model  uses  four 
dynamic  data  files:  the  unit  status  file,  the  supply  action  file,  the  supply 
status  file,  and  the  backorder  file. 

(1)  The  unit  status  file  contains  information  on  the  current  status 
of  each  unit  involved  in  the  game,  updated  as  a  result  of  any  simulated  activ¬ 
ity  involving  the  unit.  It  contains  the  quantities  of  equipment  currently  on 
hand  in  each  unit  and  points  to  the  unit's  records  on  the  supply  status  file. 

(2)  The  supply  status  file  contains  information  pertaining  to  the 
current  supply  status  of  a  unit.  For  every  resolution  unit  in  the  game,  one 
record  is  maintained  on  this  file  for  each  equipment  item  that  may  be  supplied 
to  the  unit.  (See  Chapter  3  of  this  section  for  a  discussion  of  resolution 
units. ) 


(3)  The  supply  action  file  contains  a  record  for  every  supply  action 
currently  in  process.  A  supply  action  is  the  movement  of  an  equipment  item 
order  quantity  with  its  associated  transportation  resources  from  the  supply 
point  to  the  unit  or  the  movement  of  the  transportation  resources  alone  from 
the  unit  to  the  supply  point.  These  records  are  updated  as  the  order  quantity 
and  transporting  vehicles  progress  between  supply  points  and  receiving  units. 

(4)  The  backorder  file  maintains  a  record  of  each  supply  requirement 
for  which  a  supply  action  must  be  initiated. 

c.  Model  Steps.  As  shown  in  Figure  IV-16-2,  the  major  Combat  Service 
Support  Model  steps  are:  (1)  updating  supply  action  file  entries,  (2)  creating 
resupply  orders  and  assigning  transportation  to  fill  the  resupply  orders  for 
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critical  consumables  and  expendables,  (3)  determining  losses  of 
personnel  and  major  end  items,  and  (4)  creating  replacement  orders  for 
personnel  and  major  end  items.  The  model  is  generally  entered  on 
a  periodic  basis  (currently  once  every  2  hours  in  the  DIWAG  system)  , 
and  all  pending  supply  actions  are  processed.  Next,  for  each  force 
steps  2  and  3  are  accomplished  sequentially  for  each  of  three  groups 
of  units;  front-line  maneuver  units,  other  maneuver  units  and  all 
artillery  units,  and  all  other  units.  This  sequence  of  unit  groups 
imposes  a  first  priority  level  on  the  assignment  of  transportation. 
Finally,  after  steps  2  and  3  are  completed  for  all  units,  per¬ 
sonnel  and  major  end  items  replacement  orders  are  created  sequential¬ 
ly  for  the  three  unit  groups. 

3.  SUBMODEL  SPECIFICATION'S: 

a.  Processing  of  Critical  Consumables  and  Expendables: 

(1)  General: 

(a)  Figure  IV-16-3  shows  the  processing  logic  which 
occurs  within  a  group  of  units  to  resupply  critical  consumables 

and  expendables.  Since  major  end  items  and  personnel  are  resupplied 
only  once  a  day,  a  check  has  been  incorporated  to  determine  on 
which  processing  cycle  their  resupply  is  to  be  initiated.  At  the 
appropriate  time,  losses  of  major  end  items  and  personnel  are 
accumulated  for  each  unit.  The  actual  requisitioning  of  major 
end  items  and  personnel  does  not  occur  during  the  first  pass  through 
the  units  (see  paragraph  b  below). 

(b)  Since  class  I  (food)  is  to  be  ordered  only  once 

a  day,  a  check  has  been  entered  to  determine  when  that  time  occurs. 
Only  at  the  specified  time  is  class  I  ordered.  The  quantity  ordered 
is  based  on  the  personnel  strength  of  the  unit  at  the  time  the  order 
is  initiated. 


(c)  The  flow  of  logic  illustrated  in  Figure  IV-16-3 
may  be  broken  into  three  logical  processes:  the  determination  of 
supply  requirements,  the  allocation  of  available  transportation 
means  to  meet  supply  requirements,  and  the  supply  actions  involved 
in  actually  fulfilling  supply  requirements  utilizing  the  allocated 
transportation.  Details  of  these  processes  are  contained  in  the 
following  subparagraphs. 

(2)  Determination  of  Supply  Requirements.  The  method  used 
within  DIVWAG  is  to  check  if  the  items  have  fallen  below  a  "critical" 
level  (currently  set  at  50%  of  the  authorized  amount). 

•  I,, 
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Figure  IV-16-3.  Processing  of  Critical  Consumables  and  Expendables 
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review  penH,  the  projected  usage  ra'te,  7,  and  the  mean  average  deviation, 
s,  of  that  usage  rate  are  calculated  based  on  the  exponential  averaging 
technique  of  FM  38-22  (Reference  2).  These  values  are  combined  to  de¬ 
velop  an  accelerated  usage  rate,  rq,  which  should  not  be  exceeded  in  nine 
cases  out  of  ten,  under  the  assumption  that  the  usage  rate  of  the  items 
involved  follows  a  normal  distribution.  In  the  figure,  r,  for  a  given 
review  cycle,  is  the  negative  slope  of  the  current  supply  level  line,  and  r„ 
is  the  negative  slope  of  the  projected  supply  level  line.  Next,  the  delivery 
lead  time  (DLT)  ,  or  the  amount  of  time  in  which  this  unit  could  expect  deli¬ 
very  of  supplies,  is  found;  and  the  projected  supply  level  at  current  time 
plus  DLT  is  calculated  using  the  accelerated  usage  rate  and  compensating  for 
any  supplies  already  on  order.  If  this  projected  level  is  negative,  a  supply 
order  is  placed.  The  amount  ordered  is  the  difference  between  authorized 
and  projected  levels  (where  this  projected  level  uses  the  nonaccelerated 
projection  rate) ,  compensating  again  for  items  already  ordered.  During  this 
process,  stocks  are  transferred,  within  the  unit,  from  a  bulk  loaded  status 
to  a  readily  usable  status;  and  a  constraint  factor,  reflecting  the  emergency 
of  the  order,  is  calculated  for  later  use  in  assigning  a  priority  to  the  order. 

(b)  Calculation  of  Usage  Rates: 

1.  In  calculating  usage  races,  the  model  uses  the  amount  of 
the  item  currently  in  a  readily  usable  status,  er,  currently  on  hand  but, bulk 
loaded,  ec,  and  the  amounts  authorized  in  these  categories,  ar  and  ac.  The 
projected  usage  rate  is  calculated: 


?i  -  A  *  +  B  •  r  (IV-16-1) 

where: 

r^  »  projected  usage  rate  for  this  review  period 

ri-l  “  projected  usage  rate  for  the  previous  period 

A  -  0.75  [1  -  exp  -  (h/12) ] 

B  -  1  -  A 

r  -  [(ar  -  er)  +  TRj  /  tr 

h  ■  number  of  hours  into  the  game 

tr  ■  review  period  (120  minutes) 

TR  »  amount  shifted  from  ec  to  ef  during  the  review 
cycle  in  response  to  emergency  requests. 
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This  is  a  vacation  of  the  basic  exponential  smoothing  equation,  in  which  A 
and  B  arc  constants.  As  originally  designed,  the  values  of  A  and  B  were  0.75 
and  0.25,  respectively.  These  are  arbitrarily  chosen  smoothing  constants 
intended  to  give  a  fairly  gradual  transition  from  past  to  current  history. 
They  are  subject  to  adjustment.  The  correction  factor  to  A  is  used  to  dampen 
the  effects  of  the  start  of  game  situation  in  which  no  prior  usage  rate  is 
available.  The  value  of  r  is  used  to  represent  the  usage  rate  since  the  last 
review  cycle.  After  r  has  been  computed,  the  amount  of  items  available  for 
use,  er,  is  brought  up  to  its  authorized  level,  ar,  or  as  close  thereto  as 
stocks  in  bulk,  ec,  permit.  The  equations  used  are: 

er  *  er  +  Bin  ^ar  “  er^  *  et^  (IV-16-2a) 

e't  -  et  -  min  [(ar  -  er)  ,  et]  (IV-16-2b) 


where  the  prime  (')  denotes  the  value  after  adjustment.  It  should  be  noted 
that  r  is  the  true  usage  rate  only  if  er  was  at  its  authorized  level  at  the 
beginning  of  the  review  cycle.  In  other  cases,  it  indicates  a  serious  deficit 
which  will  tend  to  increase  over  time,  thus  inflating  r"  and  driving  the  model 
to  a  more  immediate  supply  order  action. 

2!.  The  mean  average  deviation  of  the  projected  usage  rate  is 
calculated  using  the  same  exponential  smooching  weights: 

®i  "  **1-1  +  B  *  |  r  -  ri_1 J  (IV-16-3) 

where: 


S£  ■  mean  average  deviation  of  r^ 

8i-l  "  mean  average  deviation  of  r^_^ 
and  other  variables  are  previously  defined. 

2*  The  accelerated  usage  rate,  r^,  is  calculated  as: 


rq  -  f±  +  (1.3  •  1.25  •  st)  (IV-16-4) 

where  the  constant  1.3  is  used  to  give  the  approximate  ninetieth  percentile 
of  a  normal  distribution,  and  1.25  is  the  conversion  factor  from  the  mean 
average  deviation  to  Che  standard  deviation  as  provided  in  FM  38-22,  Reference  2. 
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accelerated 


(.c)  Projected  Outage.  The  projected  outage  situation,  using  the 
usage  rate,  is  determined  : 


where: 

Q  - 


Q  -  er  +  et  +  eQ  -  rq  •  d 

outage  indicator 

amount  of  the  item  currently  on  order  and 
in  the  process  of  being  delivered 

delivery  lead  time 

previously  defined. 
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The  amount  currently  in  the  process  of  being  shipped  is  determined  by  a 
review  of  all  pending  supply  action  file  records  for  which  the  unit  involved 
is  the  recipient.  This  file  is  described  in  more  detail  in  subparagraph  (4) 
below.  The  delivery  delay  time,  d,  is  determined  by: 


d 


h.  (t  +  t  ) 
d  tran  OH 


i 

(IV-16-6) 


where : 


d  -  delivery  lead  time 


h^  »■  1  if  the  unit  receives  unit  distribution  of 

the  item 

h^  ■  2  if  the  unit  receives  the  item  by  supply 

point  distribution 


ttran  ■  nominal  transport  time 


t^  *  overhead  time. 


1 


* 


Nominal  transport  time  for  this  item  is  determined  considering  the  distance  w 
between  the  unit  and  its  supplier  and  the  preferred  transport  vehicle.  The 
supplier  is  identified  as  part  of  the  original  game  task  organization  input. 
The  preferred  transport  vehicle  for  this  item  and  this  distribution  method  is 
part  of  the  Combe t  Service  Support  Model  data  base,  required  ai>  input  prior 
to  game  initiation.  The  model  obtains  (within  Movement  Model  constant  data) 
the  limiting  road  speeds  of  the  preferred  vehicle,  under  current  weather  and 
light  conditions;  averages  the  speeds,  which  are  given  for  two  terrain  < 
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conditions;  and  applies  this  average  speed  to  the  distance  between  supplier 
and  supplied  to  develop  a  nominal  transport  time.  Overhead  time,  also  part 
of  the  game  data  base,  is  intended  to  represent  normal  lumped  overhead  for 
filling  an  order,  loading  and  offloading  vehicles,  and  any  other  actions, 
exclusive  of  travel  time,  associated  with  a  request  for  this  item.  If  the 
value  of  Q  in  Equation  9-5  is  negative;  i.e.,  projected  usage  within  delivery 
lead  time  exceeds  stocks  on  hand  and  on  order,  a  new  order  is  generated.  If 
an  outage  is  projected,  the  amount  ordered  is  calculated  by  Equation  9-7: 


aQ  *  ar  +  at  -  ^er  +  et  +  eo  “  ri^  0  **  (0-7 ) 

where  aQ  =  amount  of  order,  and  the  other  variables  are  previously  defined. 
The  quantity  in  brackets  :n  Equation  9-7  is  identical  to  the  calculation  of 
Q  in  Equation  9-5,  with  the  projected  usage  rate  substituted  for  the  acceler¬ 
ated  rate.  In  both  cases,  this  is  the  projected  level  of  supply  of  the  unit 
just  prior  co  receipt  of  supplies  if  ordered  at  this  time  under  the  appro¬ 
priate  use  rates.  The  difference  between  these  levels  is  the  variable  safety 
level  of  the  logistic  modal,  a  function  of  the  mean  average  deviation  of  the 
projected  usage  level  and  the  delivery  lead  tine: 


SL  *  d(rq  ~  r^)  *  <1  '  1-625  si  C I  ^  ~  /C*  3T-8) 

SL  =  safety  level. 


(d)  Constraint  Factor.  Once  a  supply  order  is  generated,  it 
must  compete  with  other  orders  for  available  transportation  means.  To  allow 
assignment  of  priorities  among  supply  orders,  a  constraint  factor  is  computed 
for  each  item  at  each  review  period: 


ci  ■  c^  •  exp(l  -  ri/m)  JJ-9) 

where : 

c.  *  constraint  factor  for  current  review  cycle 
i 

c^_^  *  constraint  factor  of  last  review  cycle 

r^  *  current  projected  usage  rate  of  Equation  9-1 
m  *  minimum  race  (Equation  9-10). 
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The  constraint  factor  is  set  at  0.2  for  first  line  units,  0.3  for 
artillery  and  other  maneuver  units,  0.4  for  intermediate  supply 
points,  and  0.6  for  all  other  units. 

(3)  Assignment  of  Transportation.  Once  the  supply  status 
of  all  units  within  a  group  of  units  has  been  reviewed  and  any 
necessary  supply  orders  generated,  transportation  is  assigned  to 
meet  the  supply  requirements.  Each  supply  order  generated  by  the 
group  of  units  is  processed  based  on  the  priority  of  the  order; 
i.e.,  the  order  with  the  lowest  constraint  factor,  then  the  order 
with  the  next  lowest  constraint  factor,  and  so  on.  As  currently 
designed,  no  attempt  is  made  to  allocate  transportation  from  the 
total  force  resources.  Rather,  for  each  supply  order,  only  trans¬ 
portation  organic  to  the  requesting  unit  and  the  designated  point 
of  supply  is  considered. 

(a)  Logical  Flow.  The  logical  flow  of  the  transportation 
assignment  algorithm  is  shown  in  Figure  IV-16-5.  For  each  unit 
type  and  each  item  to  be  resupplied,  a  standing  operating  procedure 
(SOP)  distribution  method  is  defined  in  the  data  base  (unit  or  supply 
point  distribution).  Each  item  also  has  an  associated  supply  class. 

Three  preferred  vehicles  are  designated  for  each  distribution  method 
as  well  as  for  air  transport.  Upon  entry  to  the  algorithm,  the  SOP 
distribution  method  is  first  attempted.  The  preferred  vehicles  are  taken 
in  order  and  assigned  to  transport  the  quantity  ordered  (fractional 
vehicles  are  used).  If  sufficient  numbers  of  the  first  choice  vehicle 
are  available  in  the  requesting  (supply  point  distribution)  or  supplying 
(unit  distribution)  unit,  processing  is  completed.  If  sufficient 
vehicles  are  not  available,  all  available  vehicles  are  assigned  and 
the  process  is  repeated  for  the  remaining  order  quantity  using  the 
second  choice  vehicle.  If  the  order  is  still  unfilled,  available 
third  choice  vehicles  are  assigned.  Once  all  available  vehicles 
under  the  preferred  distribution  method  have  been  assigned,  the  same 
process  may  be  repeated  for  the  preferred  vehicles  available  in  the 
other  unit,  under  the  remaining  distribution  method,  always  working 
on  the  unfilled  portion  of  the  order.  If  the  order  remains  unfilled 
under  both  ground  distribution  methods,  a  third  cycle  may  be  tried, 
attempting  to  use  air  transport.  The  decision  to  attempt  the  alter¬ 
native  ground  transportation  method  and  air  transportation  is 
based  on  the  constraint  factor,  c^  (priority),  of  the  item. 


* 
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As  currently  programmed,  the  second  ground  distribution  method  is  attempted 
if  c^  is  less  than  0.8,  and  air  transport  is  attempted  if  Cj.  is  less  than  0.5. 
These  values  are  judgmentally  set. 

(b)  Essential  Calculations: 

_1.  General.  The  transportation  algorithm  is  essentially  a 
logical  check  and  decision  process  with  minimal  calculation  involved.  The 
necessary  calculations  are  those  used  to  determine  the  extent  to  which 
available  transportation  can  move  the  requested  amount  of  supplies.  This  is 
accomplished  by  comparing  the  weight  and  volume  of  the  order  to  weight  and 
volume  capacities  of  the  available  transport  vehicles  and  either  assigning 
as  much  of  the  available  capacity  as  is  required  to  carry  the  full  order  or 
assigning  the  total  available  transport  capacity  to  carry  as  much  of  the  order 
as  is  possible.  Within  the  process,  a  check  is  also  made  to  verify  that  the 
supply  point  under  unit  distribution  has  sufficient  stocks  to  fill  the  order. 
If  not,  all  available  stocks  are  used. 

2.  Weights  and  Volumes.  The  weight  and  volume  of  the  order 
quantity  are  calculated  by  multiplying  the  order  quantity  by  unit  bulk  weights 
and  volumes  contained  in  the  constant  data  base.  Similarly,  weight  and 
volume  transport  capacities  are  calculated  by  multiplying  the  number  of 
currently  available  (within  the  requesting  unit  for  supply  point  distribution 
or  at  the  supply  point  for  unit  distribution)  vehicles  by  the  bulk  weight 
and  volume  capacities  per  vehicle,  also  in  the  constant  data  base.  If  the 
weight  and  volume  capacities  of  available  transport  equal  or  exceed  the  weight 
and  volume  of  the  order,  the  order  can  be  transported,  and  a  percentage  of  the 
available  transport  vehicles  is  assigned: 


vt  *  va  •  Pt  “  va  *  max  (Pwt’Pvt}  (IV-16-11) 


where : 


a 

pt 

Pwt 

Pvt 


number  of  vehicles  assigned  to  the  order 

number  of  vehicles  available  in  the  unit 

max  (pwt,pvt),  the  percentage  of  transport 
capacity  assigned  for  the  order 

ratio  of  weight  of  the  order  to  weight 
transport  capacity 

ratio  of  volume  of  the  order  to  volume  of  the 
transport  capacity. 
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If  the  weight  or  volume  transport  capacity  is  exceeded  by  the  weight  or 
volume  of  the  order,  all  available  vehicles  are  assigned,  and  a  percentage 
of  the  order  is  filled  as  calculated  by: 


c,  =  c  *  p  *  c  ‘  min  (p  ,p  )  (IV-16-12) 

f  o  c  o  wc  VC 

where : 

c^  =  amount  of  the  ordered  item  to  be  transported  by 
the  assigned  vehicles 

c  =  amount  of  the  order  outstanding  up  to  this 
assignment  of  vehicles 

p  =  min  (p  ,pvc),  the  percent  of  the  order  to  be 
C  filled 

Pwc  *  ratio  of  available  transport  weight  capacity  to 
weight  of  outstanding  amount  of  order 

Pvc  =  ratio  of  available  transport  volume  capacity  to 
volume  of  outstanding  amount  of  order. 


As  an  order,  or  part  of  an  order  is  filled,  records  on  the  supply  action  file 
(discussed  in  subparagraph  (A)  below)  are  generated,  and  the  assigned  vehicles 
are  removed  from  the  unit  status  file  of  the  unit  providing  them,  thus  becom¬ 
ing  unavailable  for  assignment  until  the  supply  action  is  completed.  If  unit 
distribution  is  involved,  the  amount  of  materiel  shipped  is  removed  from  the 
status  file  of  the  supply  point.  If  this  should  exceed  stocks  on  hand  at  the 
supply  point,  only  the  amount  on  hand  is  shipped;  and  the  amount  of  transport 
involved  in  adjusted  accordingly. 

(4)  Supply  Actions.  The  supply  action  file  is  used  to  keep  track  of 
the  status  of  all  supply  actions.  As  transport  cape  ity  is  assigned  to  an 
order,  two  entries  (records)  are  initialized  on  this  file;  one  to  keep  track 
of  the  vehicles  and  one  to  keep  track  of  the  materiel  (or  personnel)  being 
transported.  Each  record  on  the  supply  action  file  contains  six  essential 
values : 


.  te,  game  time  that  the  record  is  due  to  be  updated 

.  u^,  identification  of  the  unit  generating  the  order 

.  U2,  identification  of  the  unit  filling  the  order 

.  i,  equipment  item  code,  identifying  the  item  involved 
in  the  action  (vehicle  or  consumable) 
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.  n^,  quantity  of  item  i  involved  in  the  action 

.  s,  status  flag  for  the  supply  action. 

At  the  beginning  of  each  Combat  Service  Support  Model  review  cycle,  all 
existing  records  on  the  file  are  updated.  The  actions  taken  in  initiating 
and  updating  these  records  depend  upon  whether  unit  distribution  or  supply 
point  distribution  is  involved  and  are  explained  below. 

(a)  Unit  Distribution  Supply  Actions: 

1_.  Initiation.  To  initiate  a  unit  distribution  supply  action 
record,  the  unit  identifications  u^  and  U2;  equipment  item  code,  i;  and 
quantity  of  item,  n^  are  set.  The  quantity  involved  is  that  established  by 
the  transportation  assignment  algorithm  discussed  in  subparagraph  (3)  above. 

As  discussed  in  subparagraph  (3)  above,  these  quantities  are  subtracted  from 
the  unit  status  file  of  the  providing  unit.  (For  an  initial  supply  point,  the 
quantity  of  materiel  or  personnel  is  actually  added  to  the  supply  point  unit 
status  file.  Thus,  no  limits  on  flow  of  supplies  into  the  force  are  simulated, 
and  this  unit  maintains  a  count  of  materiel  and  personnel  entered  into  the 
force  simulated  from  external  sources.)  The  time  that  the  record  is  due  to  be 
updated,  te,  is  calculated  by  adding  transit  time  for  the  vehicle  involved  to 
the  current  game  time.  Transit  time  is  calculated  based  on  the  distance  be¬ 
tween  units  and  the  mobility  characteristics  of  the  vehicle  as  described  in  sub- 
paragraph  (2)  above.  Briefly,  it  assumes  the  average  (over  terrain  types)  lim¬ 
iting  vehicle  speed  under  prevailing  light  and  weather  conditions  and  a  straight 
line  route  between  units.  The  action  status  flag  is  set  to  1,  indicating  the 
update  action  to  be  taken  at  time,  te,  is  that  for  arrival  of  unit  distribution 
at  the  receiving  unit. 

2.  Arrival  at  Receiving  Unit.  When  a  time,  te,  less  than  or 
equal  to  current  game  time  is  sensed  during  the  update  cycle  and  an  action 
status  flag  of  1  is  found,  the  arrival  at  the  receiving  unit  is  treated.  The 
action  file  record  containing  materiel  is  closed  after  the  item  quantity,  n*, 
is  added  to  the  unit's  amount  of  the  item  on  hand  in  bulk.  The  action  file 
record  containing  vehicles  is  updated  by  adding  transit  time  and  bulk  overhead 
time  for  unit  distribution  to  te  and  setting  the  action  status  flag  to  3, 
indicating  the  time  at  which  vehicles  will  be  returned  to  the  supply  point 
after  offloading  and  the  return  trip. 

Return  to  Supply  Point.  When  scheduled  action  time,  te, 
is  exceeded  by  current  review  time,  and  an  action  status  flag  of  3  is  found, 
the  vehicles  are  returned  to  the  status  file  of  the  supply  point,  becoming 
available  for  reassignment;  and  the  supply  action  record  is  removed. 
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(b)  Supply  Point  Distribution  Actions: 

1_.  Initiation.  Supply  point  distribution  action  records 
are  initiated  similarly  to  unit  distribution  records.  For  each  action,  two 
records  are  initiated;  one  for  the  vehicles  and  one  for  the  materiel  (or  per¬ 
sonnel).  The  appropriate  unit  identifications,  equipment  item  code,  equipment 
quantity,  and  times  are  set.  In  this  case,  no  check  is  made  of  the  amount  of 
materiel  available  at  the  supply  point.  The  number  of  vehicles  is  subtracted 
from  the  unit  status  file  of  the  providing  unit,  in  this  case  the  unit  initi- 
*  ating  the  requirement.  The  action  status  flag  is  set  to  2,  indicating  the 
arrival  at  the  supply  point  as  the  next  event. 

2_.  Arrival  at  Supply  Point.  When  te  is  exceeded  by  review 
time  and  an  action  flag  of  2  is  found,  actions  upon  arrival  at  the  supply 
point  are  treated  by  updating  the  supply  action  record.  The  transit  time  and 
bulk  overhead  time  for  loading  are  added  to  tg  to  obtain  the  new  event  time. 
Both  records  are  turned  around  by  inserting  the  new  event  time  and  an  action 
flag  of  4.  Additionally,  the  quantity  of  materiel  to  be  returned  to  the 
requesting  unit  is  subtracted  from  the  unit  status  file  of  the  supply  point. 

If  the  supply  point  has  insufficient  stocks,  all  available  stocks  are  taken, 
and  the  quantity  on  the  materiel  action  record  is  reduced  accordingly.  (As 
discussed  in  subparagraph  (a)  above,  there  is  no  limit  on  initial  supply 
points,  and  quantities  are  added  to  unit  status  files.) 

jL  Return  to  Requesting  Unit.  When  te  is  exceeded  by  game 
time,  and  the  action  status  flag  is  4,  the  return  trip  to  the  requesting  unit 
is  complete.  Quantities  of  vehicles  are  returned  to  the  unit  status  file 
becoming  available  for  reassignment;  quantities  of  materiel  received  are  added 
to  the  units’  on  hand  bulk  quantities;  and  the  supply  action  records  are 
removed. 


b.  Processing  of  Personnel  and  Major  End  Items: 

(1)  The  processing  which  occurs  in  determining  the  quantities  of 
major  end  items  and  personnel  to  be  supplied  to  the  various  units  is  displayed 
in  Figure  IV-16-6.  The  flow  can  be  broken  into  two  logical  processes:  deter¬ 
mination  of  replacement  quantities  and  creation  of  supply  actions. 

(2)  As  losses  of  personnel  and  major  end  items  are  calculated  for 
each  unit,  they  are  accumulated  for  each  unit  group.  The  available  resources 
are  first  compared  with  the  requirements  of  the  front-line  maneuver  units. 

If  available  resources  are  sufficient  to  meet  their  requirements,  then  the 
front-line  units  are  allotted  enough  replacements  to  satisfy  their  needs.  All 
artillery  units  and  any  other  maneuver  units  are  then  examined.  If  their 
’  requirements  can  also  be  met,  then  all  remaining  units  are  examined. 

(a)  When  sufficient  quantities  of  a  major  end  item  or  personnel 
are  not  available  to  satisfy  the  total  requirements  of  a  unit  group,  the 
quantity  available  is  prorated  to  the  units  based  on  the  units'  losses.  As 
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Figure  IV-16-6.  Processing  of  Major  End  Items  and  Personnel 
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an  example,  if  10  tanks  are  available  for  resupply  but  a  need  exists  for 
20  (6  to  one  unit  and  14  to  a  second  unit),  then  the  first  unit  would  receive 
three  and  the  second  unit  would  receive  seven.  If  after  the  front  line  maneu¬ 
ver  units'  requirements  are  met,  no  resources  are  available,  the  remaining 
unit  groups  are  not  allocated  replenishment  or  replacements.  Similarly,  if 
the  second  unit  group's  requirements  cannot  be  met,  then  the  third  unit  does 
not  receive  replenishment  or  replacements. 

(b)  The  number  of  personnel  and  quantity  of  major  end  items  of 
equipment  that  will  be  available  to  the  division  for  resupply  on  each  day  of 
combat  are  specified  pregame  for  each  major  end  item.  Items  not  used  on  a 
given  day  are  added  to  the  next  day's  available  quantity. 

(3)  Supply  Actions.  The  supply  action  file  is  used  to  maintain  the 

status  of  all  supply  actions.  As  personnel  and  major  end  items  are  allocated, 

an  entry  (record)  is  initialized  on  this  file.  Six  essential  values  are  con¬ 
tained  on  the  supply  action  file  record.  These  values  were  delineated  in  sub- 

paragraph  a(4)  above.  The  status  flag  for  this  action  is  set  equal  to  5.  The 

time  that  the  record  is  due  to  be  updated  is  set  equal  to  current  time  plus 
the  time  required  for  the  item  or  its  transporter  to  travel  from  the  division 
rear  services  area  to  the  receiving  unit.  The  rate  of  movement  is  the  road 
movement  rate  of  the  major  end  item  if  it  is  self-propelled;  otherwise,  the 
rate  is  that  of  the  transporter.  When  the  replacements  reach  the  receiving 
unit,  they  are  immediately  added  to  the  unit's  status  file. 

4.  HISTORY  TAPE  OUTPUT.  The  Combat  Service  Support  Model  writes  the  following 
event  records  onto  the  period  history  tape. 


Record 

Type 

Title 

Frequency 

511 

Backorder  Event 

One  record  for  each 
backorder  processed. 

521 

Supply  Action  Event 

One  record  for  each 

supply  action  processed 

The  detailed 
of  Appendix  A 

description  of  the  record  formats 
to  Chapter  1  of  Section  VI. 

is  presented  in  paragraph  2c 

APPENDIX  A 


COMBAT  SERVICE  SUPPORT  MODEL  INPUT  REQUIREMENTS 

1.  INTRODUCTION.  The  Combat  Service  Support  Model  simulates  all  resupply  and 
replacement  functions  except  the  rearming  and  refueling  of  Blue  army  aircraft 
performing  airmobile  operations.  The  Airmobile  Model  simulates  these  aspects 
of  combat  service  support.  Subsistence,  fuel,  barrier  materiels,  ammunitions, 

«  and  major  end  items  are  the  major  classes  of  supply  (I,  III,  IV,  V,  and  VII, 
respectively)  of  which  replacement  is  simulated  by  the  DIVWAG  system.  Data 
loaded  for  TOE  load,  movement,  task  organization,  terrain,  weather,  and  other 
operations  are  also  used  by  Combat  Service  Support;  thus,  there  is  a  relation¬ 
ship  between  the  Combat  Service  Support  Model  and  the  constant  data  inputs  of 
the  other  models.  This  appendix  provides  the  instructions  needed  for  completing 
data  entries  for  constant  data  input  to  the  Combat  Service  Support  Model.  Suc¬ 
ceeding  paragraphs  detail  the  information  necessary  to  complete  the  forms  used 
to  enter  data  in  the  desired  format. 

a.  Supply.  The  Combat  Service  Support  Model  uses  the  supply  organization 
specified  for  each  force  by  pregame  input  as  described  in  Chapter  3  of  this 
section,  which  also  describes  how  consumable  supplies  are  loaded  for  each  unit. 
Those  instructions  cover  both  supplies  carried  by  the  individual  men,  weapons, 
and  vehicles  of  the  unit  and  bulk  quantities  of  supplies  carried  by  vehicles 
of  the  unit's  trains.  The  Combat  Service  Support  Model  monitors  the  level  of 
supplies  within  units  and  replaces  supplies  as  consumption  and  combat  losses 
occur. 


b.  Data  Requirements.  The  Combat  Service  Support  Model  simulates  the 
replacement  of  personnel,  replenishment  of  expendable  and  consumable  supplies, 
and  resupply  of  major  end  items  of  equipment.  The  data  requirements  are  those 
associated  with  the  transport  needed  to  move  the  supplies;  the  physical  dimen¬ 
sions  of  the  consumable  and  major  equipment  items;  the  preferred  means  of  trans¬ 
port;  and,  if  there  are  alternatives,  the  ranking  of  the  transport  alternatives. 
All  the  data  requirements  for  this  model  are  not  satisfied  by  the  CSS  load  pro¬ 
gram.  Data  must  be  obtained  from  the  unit  status  file  to  determine  how  many 
vehicles  are  available  to  move  supplies.  If  some  were  lost,  it  requires  a 
longer  period  of  time  to  transport  the  same  load  since  many  more  round  trips 
are  required.  If  other  supply-consuming  equipments  were  also  destroyed,  and 
hostile  forces  reduced  the  combat  effectiveness  of  several  units,  there  would 

be  a  lesser  demand  for  supplies.  These  considerations,  plus  other  logistical 
support  factors,  are  included  in  the  model. 

c.  Data  Base.  The  cc.  ..'ant  data  input  for  the  Combat  Service  Support 

•  Model  is  loaded  into  data  file  11  and  is  accessed  by  the  model  as  needed  dynami¬ 
cally  during  the  course  of  the  war  game.  Figure  IV-16-A-1,  Combat  Service  Sup¬ 
port  Data  Base,  illustrates  the  configuration  of  the  data  base.  Four  different 
card  formats  ar^  used  for  entering  data  into  data  file  11,  which  is  directly 
concerned  with  the  Combat  Service  Support  Model's  constant  data  inputs.  Each 
card  is  identified  with  the  card  identification  number  that  is  always  entered 


t 
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A-l .  Combat  Service  Support  Data  Base 
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in  card  columns  73-76.  The  details  of  entering  data  in  these  card  formats  are 
explained  in  the  following  paragraphs  of  this  chapter.  A  brief  explanation  of 
each  follows: 

(1)  Elapsed  Time  in  Handling  Transports.  This  format  is  card 
identification  1101,  which  indicates  that  the  card  is  the  first  of  the  1100 
series  and  the  data  are  to  be  loaded  into  data  file  11.  This  card  format  con¬ 
tains  delay  time  data  on  truck  loading,  unloading,  start-up,  forming  convoys, 
and  the  like. 

(2)  Items  by  Class  of  Supply.  In  Figure  IV-16-A-1  this  card  is 
identified  as  1102,  indicating  that  it  is  the  second  series  of  card  formats  to 
be  entered  in  data  file  11.  The  categorization  of  each  item,  identified  by 
equipment  item  code,  to  the  class  of  supply  to  which  it  may  be  assigned  is  the 
type  of  data  to  be  recorded  in  this  card  format.  Data  to  be  entered  are  con¬ 
cerned  with  the  rated  weights  and  volume  (cube)  of  each  item  used.  The  cube 
and  weight  are  on  a  per-unit  basis.  These  data  are  compared  with  the  hauling 
capability  of  the  transport  selected  to  make  certain  that  there  is  a  match  or 
that  items  are  not  transported  about  the  battlefield  unless  such  a  match  exists. 
Additionally,  this  card  is  designed  to  record  the  data  that  rank  the  transports 
in  terms  of  type  of  hauling  to  be  done  and  the  adaptability  of  the  vehicle  for 
the  load  to  be  carried. 

(3)  Weights  and  Volumes  Carried  by  Transports.  The  capability  of  a 
transport  to  carry  the  supplied  item  is  contained  in  the  data  to  be  entered 
in  this  card  format.  The  identification  of  1103  has  been  assigned  to  this 
card  format,  the  third  in  the  series  being  loaded  into  data  file  11. 

(4)  Class  VII  and  Personnel  Available  for  Resupply  by  Day.  This  card, 
1104,  specifies  the  number  of  personnel  and  major  end  items  of  equipment  that 
are  available  for  resupply  by  day. 

2.  ELAPSED  TIME  TO  HANDLE  TRANSPORTS  AND  CLASS  I  CONSUMPTION  RATES.  The  data 
to  be  included  in  this  card  format  (ID  1101,  Figure  IV-16-A-2)  are  elapsed  time 
to  start,  load,  and  unload  trucks,  and  to  load  and  unload  aircraft.  In  addi¬ 
tion,  the  rate  of  consumption  of  class  I,  subsistence,  in  pounds  per  man  per 

day  is  indicated.  One  card  is  prepared  for  each  force. 

a.  Card  Type  (Column  1).  Card  column  1  has  the  number  1  preprinted,  and 
no  changes  are  to  be  made.  In  card  column  2  enter  "R"  for  the  Red  force  or 
"B"  for  the  Blue  force. 

b.  Minutes  Elapsed  Time  to  Load  Trucks,  Unit  Distribution  (Columns  6-9). 

Regardless  of  the  type  of  truck  and  the  capacity  in  weight  or  cube,  enter  the 
time  in  minutes  that  will  elapse  from  the  start  to  finish  of  loading  a  truck 

when  used  in  unit  distribution.  This  entry  is  an  average  and  does  not  neces¬ 

sarily  represent  the  times  for  a  specific  transport  or  specific  consumable. 

c.  Minutes  Elapsed  Time  to  Start  Trucks  (Columns  12-15).  Enter  in  minutes 
the  elapsed  time  to  start  trucks  and  organize  convoys. 
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d.  Minutes  Elapsed  Time  to  Unload  Unit  Distribution  Trucks  at  Destination 
(Columns’  18-21) .  This  time  is  the  minutes  needed  to  unload  unit  distribution 
trucks  at  their  destination.  Use  an  average  figure  for  the  different  types 

of  transports  used  in  the  game  as  the  time  period  required  to  unload  any  one 
truck.  The  time  entered  is  for  an  individual  truck  with  its  full  complement 
of  personnel. 

e.  Minutes  Elapsed  Time  to  Load  Trucks  at  the  Supply  Point  (Columns 
24-27).  Enter  the  time  to  load  trucks  at  the  supply  point.  The  time 

•  represents  an  average  for  all  type  trucks. 

f.  Class  I  Pounds /Man/Day  (Columns  33-35).  Enter  the  subsistence 
consumption  rate  on  a  per-man-per-day  basis.  No  decimals  or  fractions  are 
to  be  entered;  only  whole  numbers  are  permitted.  Fractions  or  decimals  will 
be  rounded  to  the  nearest  whole  number.  Packaged  weights  are  used. 

g.  Minutes  to  Load  Aircraft  (Columns  38-41).  Enter  the  average  time 
required  to  load  aircraft.  The  entry  represents  an  average  for  all  type 
loads  for  all  type  aircraft  used  by  the  force  to  transport  personnel, 
supplies,  and  equipment. 

h.  Minutes  to  Unload  Aircraft  (Columns  44-47).  Enter  the  average  time 
required  to  unload  aircraft.  The  entry  represents  an  average  for  all  type 
loads  for  all  type  aircraft  used  by  the  force  to  transport  personnel, 
supplies,  and  equipment. 

3.  ITEMS  BY  SUPPLY  CLASS.  Each  item  is  identified  by  the  class  of  supply  to 
which  it  is  assigned  (card  ID  1102,  Figure  IV-16-A-j).  This  entry  is  used  to 
establish  the  relationship  between  the  consuming  unit  and  the  unit  which  pro¬ 
vides  its  logistics  support.  For  example,  a  quartermaster  company  may  be  given 
the  mission  of  supplying  subsistence  to  designated  units.  This  mission  would 
be  specified  as  described  in  Chapter  3.  Equipment  item  codes  that  represent 
food,  class  I,  are  assigned  an  equipment  item  code  of  1  (both  forces  use  this 
code).  When  replenishment  of  consumable  1  is  needed  for  a  specific  unit  the 
Combat  Service  Support  Model  searches  the  supply  organizations  and  determines 
the  unit  that  issues  class  I  supplies  to  the  specific  unit.  The  model  then 
performs  the  necessary  activities  needed  in  replenishment,  such  as  determining 
the  location  of  the  class  I  issue  unit,  time  and  distance  factors  to  the  unit 
that  is  to  draw  rations,  quantity  of  rations  required,  and  transport  needed 
with  fuel  consumption. 

a.  Card  Format.  One  card  is  required  for  each  item  code  to  be  played 
during  the  game. 

*  b.  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  1  has  been 
preprinted  in  card  column  1.  In  card  column  2  enter  "R"  for  Red  forces  or 
"B"  for  Blue  forces. 

c.  Equipment  Item  Code  (Columns  5-7).  Enter  the  equipment  item  code 
in  card  columns  5  to  7  (right  justified).  A  card  for  personnel  replacement 
should  also  be  prepared  for  each  force  with  the  characters  PER  in  columns  5-7. 
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Figure  IV-16-A-3.  Items  of  Supply  by  Class  Card  Format 


d.  Class  of  Supply  (Columns  9-10).  Enter,  In  Arabic  numerals,  the  class 
of  supply  to  which  the  item  listed  in  card  columns  5-7  is  assigned.  For 
personnel,  enter  the  number  10  in  columns  9-10. 

e.  Pounds  of  Weight  (Columns  12-19).  In  these  columns  enter  the  weight 
of  each  item  code  on  a  per-unit  basis.  There  is  an  understood  decimal 
between  columns  17  and  18.  If  the  item  weighs  less  than  1  pound,  enter  its 
weight  as  a  decimal  fraction. 

f.  Volume  in  Cubic  Feet  (Columns  21-28).  In  these  columns  enter  the 
cubic  feet  of  volume  for  the  item.  If  a  consumable  is  shipped  to  the  using 
unit  with  appropriate  crating,  preservatives,  and  the  like,  then  these  items 
should  be  included  in  the  cube  dimension.  If  the  item  will  be  transported  as 
part  of  an  airmobile  movement  during  the  game,  but  not  necessarily  resupplied, 
the  volume  must  be  specified  here.  There  is  an  understood  decimal  between 
columns  26  and  27.  If  the  item's  cube  is  less  than  1  cubic  foot,  enter  its 
cube  as  a  decimal  fraction. 

g.  Transport  Preference  (Columns  30-64).  In  these  series  of  card  columns 
are  entered  the  preferences  for  use  of  transports  to  haul  the  item  listed  in 
card  columns  5-7.  There  are  three  conditions  under  which  transport  types  are 
to  be  nominated  in  order  of  preference.  The  first  is  unit  distribution,  the 
second  is  supply  point  distribution,  and  the  third  is  airlift  of  the  item.  In 
simulating  the  resupply  of  consumables  to  a  given  unit,  the  Combat  Service  Sup¬ 
port  Model  first  attempts  to  use  the  distribution  method  indicated  on  card  ID 
5201,  type  2.  If  game  conditions  make  this  method  impossible,  the  model  tries 
alternative  methods.  For  example,  if  supply  point  distribution  was  specified 
for  class  V,  and  the  unit  had  lost  its  trucks,  the  model  attempts  resupply 
using  the  unit  distribution  method.  As  a  last  resort,  and  when  the  need  is 
sufficiently  critical,  the  model  resorts  to  airlift  to  accomplish  resupply  of 
the  unit. 

(1)  Unit  Distribution  (Columns  30-40).  Unit  distribution  entries 
need  not  exclude  entries  in  the  supply  point  distribution  transport  preference 
except  for  class  VII,  which  will  be  supplied  only  through  unit  distribution. 

(a)  First  Preference  (Columns  30-32).  Enter  the  equipment  item 
code  for  the  transport  considered  the  first  preference  for  hauling  the  item 
listed  in  columns  5-7.  If  the  item  is  class  VII  (major  end  items)  and  capable 
of  transporting  itself,  the  item  code  of  the  item  to  be  resupplied  should  be 
entered  here. 

(b)  Second  Preference  (Columns  34-36).  Enter  the  equipment  item 
code  for  the  transport  considered  the  second  preference  for  hauling  the  item 
stated  in  columns  5-7. 

(c)  Third  Preference  (Columns  50-52).  Enter  the  equipment  item 
code  for  the  transport  considered  the  third  preference  for  hauling  this 
consumable  stated  in  columns  5-7. 
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(2)  Supply  Point  Distribution  (Columns  42-52) .  Supply  point 
distribution  channel  entries  need  not  exclude  entries  in  unit  distribution 
for  the  specific  item  in  columns  5-7,  except  for  class  VII  items. 

(a)  First  Preference  (Columns  42-44).  Enter  the  equipment 
item  code  for  the  transport  considered  the  first  preference  for  hauling  the 
item  stated  in  columns  5-7. 

(b)  Second  Preference  (Columns  46-48) .  Enter  the  equipment  item 
code  for  the  transport  considered  the  second  preference  for  hauling  the 

item  stated  in  columns  5-7. 

(c)  Third  Preference  (Columns  50-52) .  Enter  the  equipment  item 
code  for  the  transport  considered  the  third  preference  for  hauling  this 
consumable  stated  in  columns  5-7. 

(3)  Airlift  (Columns  54-64).  Regardless  of  the  stated  preference  for 
either  supply  or  unit  distribution,  if  this  item  were  to  be  airlifted  the  pref 
erence  for  type  of  aircraft  is  stated  here.  Since  not  all  items  are  airlifted 
an  entry  in  this  field  is  not  always  appropriate;  however,  there  are  no  model 
limitations  that  would  preclude  any  item  from  being  airlifted. 

(a)  First  Preference  (Columns  54-56).  Enter  the  equipment  item 
code  of  the  aircraft  of  first  preference  for  airlifting  the  item  in  columns 
5-7. 

(b)  Second  Preference  (Columns  58-60) .  Enter  the  equipment  item 
code  of  the  aircraft  of  second  preference  for  airlifting  the  item  in  columns 


(c)  Third  Preference  (Columns  62-64).  Enter  the  equipment  item 
code  of  the  aircraft  of  third  preference  for  airlifting  the  item  in  columns 

4.  WEIGHTS  AMD  VOLUMES  CARRIED  BY  VARIOUS  TRANSPORTS.  As  part  of  the  Combat 
Service  Support  Model's  simulation  of  resupply  operations,  the  capacity  of 
transport  equipment  is  measured  against  the  weight  and  volume  of  the  materiel 
to  be  resupplied.  For  this  reason,  the  performance  factors  for  each  transport 
are  entered  on  this  form  (card  ID  1103,  Figure  IV-16-A-4). 

a.  Card  Format.  Each  card  has  the  capability  of  recording  the  carrying 
capacity  of  three  transports.  It  is  probable  that  more  than  three  transports 
will  be  issued  to  each  opposing  force  (the  model  accommodates  up  to  50  per 
force);  therefore,  each  force  may  have  two  or  more  of  these  cards. 

b.  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  1  has  been 
preprinted  in  column  1,  and  no  changes  are  to  be  made.  In  column  2  only 

an  "R"  for  Red  forces  or  "B"  for  Blue  forces  is  to  be  entered. 

c.  Transport  Equipment  Item  Code  Number  (Columns  5-7) .  Enter  the 
equipment  item  code  number  for  each  transport. 
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Figure  IV  16-A-4.  Weights  and  Volumes  of  Transport  Capacities  Card  Format 


d.  Pounds  of  Weight  the  Transport  is  Capable  of  Carrying  (Columns  3-15). 

The  weight  in  pounds  that  this  transport  is  capable  of  hauling  is  entered  here. 
This  value  is  its  rated  load  carrying  capability.  There  is  an  understood 
decimal  between  columns  13  and  14. 

e.  Volume  in  Cubic  Feet  (Columns  16-23).  The  volume  of  the  payload  for 
this  specific  transport  is  the  entry  made  in  these  columns.  Because  the  sling 
load  capabilities  of  some  helicopters  make  this  constraint  inappropriate,  a 
series  of  eight  nines  (99999999)  is  entered  in  this  field  when  applicable. 

There  is  an  understood  decimal  between  columns  21  and  22. 

f.  Other  Transports  and  Their  Physical  Carrying  Capacities  (Columns 
26-65).  As  mentioned  earlier  there  are  provisions  in  these  card  columns  for 
the  entry  of  two  additional  transports,  making  three  total  for  the  entire 
card.  In  all  probability  each  of  the  opposing  forces  will  have  more  than 
three  different  type  transports  for  movement  of  consumables  about  the  battle¬ 
field  and  in  support  of  its  troops.  The  data  to  be  entered  for  these  addi¬ 
tional  transports  will  be  prepared  in  the  same  manner  as  explained  in  the 
preceding  subparagraphs. 

g.  Additional  Cards.  The  process  of  preparing  the  load-carrying 
capacities  of  the  various  transports  for  each  of  the  opposing  forces  may 
require  more  than  one  card.  Each  additional  card  that  is  prepared  will  have 
the  following  as  standard  entries  in  addition  to  the  explanation  of  entries 
given  in  the  foregoing  subparagraphs. 

(1)  The  number  1  will  always  be  entered  in  card  column  1. 

(2)  "R"  or  "B"  will  be  entered  in  card  column  2. 

(3)  In  card  columns  73-76  the  numbers  1103  will  be  written. 

5.  RESUPPLY  OF  CLASS  VII  AND  PERSONNEL.  The  number  of  personnel  and  quantity 
of  major  end  items  of  equipment  (class  VII)  that  are  available  for  resupply  by 
day  (card  ID  1104,  Figure  IV-16-A-5)  must  be  specified.  The  Combat  Service 
Support  Model  performs  the  necessary  activities  needed  to  resupply  the  person¬ 
nel  and  class  VII  items  based  on  the  quantity  available  for  resupply;  however, 
the  quantity  available  on  one  or  more  days  which  is  not  resupplied  will  be  added 
to  the  next  day  on  which  resupply  is  requested.  In  other  words,  if  the  item  is 
not  resupplied,  the  quantity  available  for  resupply  is  cumulative  through  the 
current  day.  In  those  cases  where  replacement  of  personnel  casualties  and  losses 
of  major  end  items  of  equipment  for  either  the  Red  or  the  Blue  force  is  not 
desired,  make  no  entries  for  that  force.  In  such  cases,  the  model  does  not 
resupply.  Similarly,  when  resupply  for  one  or  more  days  is  not  desired,  the 
absence  of  entries  for  those  days  results  in  no  resupply  on  those  days. 

a.  Card  Format.  One  card  is  required  for  each  item  code  that  may  be 
resupplied  during  the  play  of  the  game. 
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Figure  IV-16-A-5.  Class  VII  and  Personnel  Available  for  Resupply  by  Day  Card  Format 


b.  Card  Type  and  Force  Designator  (Columns  1-2).  The  number  1  has  been 
preprinted  in  card  column  1.  In  card  column  2  enter  "R"  for  Red  forces  or 
"B"  for  Blue  forces. 

c.  Equipment  Item  Code  (Columns  5-7).  Enter  the  equipment  item  code 
in  card  columns  5-7  (right  justified).  A  card  for  personnel  replacement 
should  also  be  prepared  for  each  force,  with  the  characters  PER  in  columns 
5-7. 


d.  Day  for  Resupply  (Columns  9-10) .  Enter  the  day  on  which  resupply  of 
this  item  can  be  effected.  The  day  is  right  justified  in  column  10. 

e.  Amount  Available  for  Resupply  (Columns  12-16).  Enter  the  amount  of 
the  item  available  for  resupply  on  the  day  listed  in  card  columns  9-10. 

f.  Day  for  Resupply  (Columns  18-19).  Enter  the  day  on  which  resupply  of 
this  item  can  be  effected.  The  day  is  right  justified  in  column  19. 

g.  Amount  Available  for  Resupply  (Columns  21-25) .  Enter  the  amount  of 
the  item  available  for  resupply  on  the  day  listed  in  card  columns  18-19. 

h.  Day  for  Resupply  (Columns  27-28) .  Enter  the  day  on  which  resupply  of 
this  item  can  be  effected.  The  day  is  right  justified  in  column  28. 

i.  Amount  Available  for  Resupply  (Columns  30-34).  Enter  the  amount  of 
the  item  available  for  resupply  on  the  day  listed  in  card  columns  27-28. 

j.  Day  for  Resupply  (Columns  36-37).  Enter  the  day  on  which  resupply  of 
this  item  can  be  effected.  The  day  is  right  justified  in  column  37. 

k.  Amount  Available  for  Resupply  (Columns  39-43).  Enter  the  amount  of 
the  item  available  for  resupply  on  the  day  listed  in  card  columns  36-37. 

l.  Day  for  Resupply  (Columns  45-46).  Enter  the  day  on  which  resupply  of 
this  item  can  be  effected.  The  day  is  right  justified  in  column  46. 

m.  Amount  Available  for  Resupply  (Columns  48-52).  Enter  the  amount  of 
the  item  available  for  resupply  on  the  day  listed  in  card  columns  45-46. 

n.  Day  for  Resupply  (Columns  54-55).  Enter  the  day  on  which  resupply 
of  this  item  can  be  effected.  The  day  is  right  justified  in  column  55. 

o.  Amount  Available  for  Resupply  (Columns  57-61) .  Enter  the  amount  of 
the  item  available  for  resupply  on  the  day  listed  in  card  columns  54-55. 

p.  Day  for  Resupply  (Columns  63-64).  Enter  the  day  on  which  resupply  of 
this  item  can  be  effected.  The  day  is  right  justified  in  column  64. 

q.  Amount  Available  for  Resupply  (Columns  66-70).  Enter  the  amount  of 
the  item  available  for  resupply  on  the  day  listed  in  card  columns  63-64. 
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r.  Additional  Cards.  The  process  of  specifying  the  days  available  for 
resupplying  each  item  of  equipment  or  personnel  may  require  more  than  one 
card.  Each  additional  card  is  prepared  in  the  same  format  as  described  in 
the  preceding  subparagraphs.  The  maximum  number  of  daily  increments  for 
resupply  is  14. 

6.  COMBAT  SERVICE  SUPPORT  CONSTANT  DATA  DECK  STRUCTURE.  This  paragraph 
describes  the  data  deck  structure  for  constant  data  input  used  in  the  Combat 
Service  Support  Model;  i.e.,  the  cards  making  up  the  deck  and  the  order  in 
which  they  must  be  read  into  the  DIVUAG  system. 

a.  Combat  Service  Support  Constant  Data  Input  Cards.  The  different  card 
formats  used  to  enter  constant  data  inputs  for  the  Combat  Service  Support  Model 
are  listed  in  Figure  IV-16-A-6.  In  the  figure  the  numbers  1101  indicate  that 
the  card  is  to  load  data  in  data  file  11  and  is  the  first  card  format  of  that 
series.  At  the  far  right  is  the  program  name  for  loading  the  data  in  each  of 
the  files.  These  card  formats  are  used  to  create  and  update  the  constant  data 
input  files  for  the  Combat  Service  Support  Model. 


Card 

Type 

Card  Title 

Card 

ID 

Load 

Program  Name 

1 

Elapsed  Time  to  Handle  Vehicles  and 

Class  I  Consumption  Rate 

1101 

CSSLD 

1 

Items  of  Supply  by  Class 

1102 

CSSLD 

1 

Weight  and  Volume  Capacity  of  Transports 

1103 

CSSLD 

1 

Class  VII  and  Personnel  Available 
for  Resupply  by  Day 

1104 

CSSLD 

Figure  IV-16-A-6.  Combat  Service  Support  Card  Format  Listings 


b.  Creating  Constant  Data  Files  for  Combat  Service  Support.  The  Combat 
Service  Support  constant  data  input  files  are  created  by  reading  in  the  data 
decks  structured  as  illustrated  in  Figure  IV-16-A-7.  At  the  right  of  the 
figure  are  displayed  two  subdecks,  one  for  Blue  forces  and  the  other  for  Red 
forces.  A  breakout  of  each  subdeck  is  shown  in  the  left  side  of  the  figure. 
Tne  card  groupings  are  segregated  by  card  ID  with  a  group  header  card,  which 
is  blank  except  for  the  card  ID,  preceding  each  group. 
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(1)  Elapsed  Time  to  Handl ’  Vehicles  and  Class  I  Consumption  Rate. 

At  the  forefront  on  the  left  is  card  type  1,  ID  1101.  The  ID  1101  card 
should  be  placed  first  in  each  of  the  subdecks  for  Blue  and  Red  forces.  It 
is  also  allowable  to  put  the  Blue  ID  1101  card  and  the  Red  ID  1101  card  into 
a  common  ID  1101  group.  The  ID  1101  cards  must  be  preceded  by  an  1101  header 
card. 


(2)  Items  of  Supply  by  Class.  The  next  group  is  that  for  defining 
items  of  supply,  card  type  1,  ID  1102.  The  card  group  for  ID  1102  is 
preceded  by  an  1102  header  card  and  follows  the  ID  1101  card  group. 

(3)  Weight  and  Volume  Capacity  of  Transports.  The  third  group 
of  cards  is  card  type  1,  ID  1103,  which  defines  capacities  of  transport 
vehicles.  The  ID  1103  card  group,  including  an  1103  header  card,  is  placed 
immediately  behind  the  ID  1102  card  group. 

(4)  Class  VII  and  Personnel  Resupply  by  Day.  The  last  card  group 
is  card  type  1,  ID  1104.  This  group  is  placed  immediately  following  the 

card  group  for  ID  1103.  The  ID  1104  card  group  must  have  an  1104  header  card. 

c.  Updating  Combat  Service  Support  Constant  Data  Files.  Changes  to  the 
data  deck  read  into  the  constant  data  files  for  Combat  Service  Support  can 
be  readily  accomplished  through  the  use  of  the  retained  data  deck.  The 
updating  consists  of  correction  of  an  error  in  a  data  element,  deletion 
of  information,  or  addition  of  new  data.  The  procedures  outlined  below 
govern  these  processes. 

(1)  Correcting  an  Error.  The  card  with  the  error  is  located  and  a 
new  card  produced  with  the  changed  data  punched  in.  The  old  card  is  then 
removed  from  the  deck  and  the  newly  produced  card  is  inserted  in  its  location. 
The  entire  data  deck  for  both  the  Red  and  the  Blue  forces  is  then  submitted 
for  another  run  on  the  computer  system.  The  recreation  of  the  constant  data 
files  through  reading  in  the  deck  with  the  changed  data  on  cards  constitutes 
the  correction  of  an  error  or  change  of  a  data  element. 

(2)  Deletion  of  Information.  The  deletion  process  consists  of 
eliminating  the  entire  file,  deleting  one  data  element,  or  zeroing  out  a 
record.  For  eliminating  a  complete  disk  storage,  the  control  cards  for  the 
system  are  used.  To  delete  a  data  element,  select  the  cards  that  have  unwanted 
data,  remove  them  from  the  data  deck,  and  resubmit  the  deck  to  the  computer 
system.  The  omission  of  those  cards  and  the  recreation  of  the  data  files  for 
constant  data  inputs  for  the  Combat  Service  Support  Model  causes  that  data  to 
be  erased  from  the  files. 

(3)  Addition  of  Data.  This  procedure  also  uses  the  retained  complete 
data  deck.  First,  the  data  to  be  added  are  prepared  in  punch  card  form  and 
integrated  into  the  data  decks.  When  each  set  of  newly  produced  cards  has  been 
added,  the  deck  is  assembled  and  resubmitted  to  the  computer  system  for  reread. 
Each  time  data  are  entered  in  the  constant  data  files  for  Combat  Service  Sup¬ 
port,  a  printout  report  series  is  generated  which  displays  the  information 
appearing  in  the  files. 
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APPENDIX  B 


COMBAT  SERVICE  SUPPORT  MODEL  PROGRAM  DESCRIPTIONS 


1.  INTRODUCTION.  The  Combat  Service  Support  Model  comprises  eight  routines. 
SERSUP,  the  major  routine,  performs  necessary  resupply  calculations.  It  is 
supported  by  specialized  utility  routines  TRNTIM,  EVTFIL,  SUPFIL,  BOFILE, 

FETCH,  MISOUT,  RESLVE,  and  CSSANL.  The  macro  flow  of  the  Combat  Service 
Support  Model  is  shown  in  Figures  IV-16-2,  IV-16-3,  IV-16-5,  and  IV-16-6. 

2.  ROUTINE  SERSUP: 

a.  Purpose.  SERSUP  is  the  controlling  routine  and  performs  the  bulk  of 
calculations  required  for  the  Combat  Service  Support  Model.  The  routine  has 
three  major  loops.  The  first  loop  processes  all  pending  supply  actions.  The 
second  major  loop  creates  new  backorders  for  critical  consumables  and  expend¬ 
ables  and  processes  these  backorders  by  assigning  available  transport.  The 
third  loop  allocates  replacements  of  personnel  and  major  end  items.  Both  the 
second  and  third  major  loops  are  executed  three  times.  First,  they  are 
executed  for  front-line  maneuver  units;  secondly,  for  artillery  units  and  other 
maneuver  units;  and,  finally,  for  all  other  units. 

b.  Input  Variables: 

(1)  Standard  Common  Block  Areas: 

.  UMAIN  .  IRFOOD  .  DAY  .  EENT 

.  UCOOP  .  SWITCH  .  HOUR  .  UTDTAB 

.  WE AT HR  .  BPOINT  .  MINUTE  .  UNTLOC 

.  IBFOOD  .  RPOINT  .  BMNT  .  LETTER 

(2)  Other  Variables: 

Name  Source  Contents 

EVTAB  (7)  DF11  Area  holding  a  seven-word  pending  supply 

action  entry. 

SUPREC  (10)  DF31  Area  holding  a  ten-word  supply  status  record. 

BO  (3)  DF11  Area  holding  a  three-word  backorder  record. 

IARRAY  f412)  DF11  Transport  load  and  unload  times  equipment 

item  code/supplv  class  cross  references. 


*  NOEVNT  DF11  Number  of  pending  supply  action  entries  for 

this  update  cycle. 

NEMPTY  DF11  Pointer  to  start  of  supply  action  file  on  DF11. 

t 
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Name 

Source 

Contents 

NSIZE 

DF11 

Pointer  to  end  of  supply  action  file  on  DF11. 

CROSS 

(11) 

DF11 

List  of  transports  eligible  to  haul  a  particular 
equipment  item  plus  weight  and  volume  of 
equipment  items. 

TRANWV 

(3,50) 

DF11 

Equipment  item  code,  weight  capacity,  and 
volume  capacity  for  50  types  of  transport 
vehicles. 

AVAIL 

(201) 

DF11 

Number  of  each  equipment  item  available  for 
resupply  for  each  day. 

FUN  IT 

ZONDAT 

IUID  for  maximum  of  20  front-line  units. 

MCLASB 

(200) 

DF9 

Mobility  classes  of  Blue  force  equipment. 

MCLASR 

(200) 

DF9 

Mobility  classes  of  Red  force  equipment. 

IRAT1B 

(20) 

DF14 

Vehicle  movement  rates,  terrain  type  1, 

Blue  force. 

IRAT2B 

(20) 

DF14 

Vehicle  movement  rates,  terrain  type  2, 

Blue  force. 

IRATE 1 

(20) 

DF14 

Vehicle  movement  rates,  terrain  type  1, 

Red  force. 

IRATE2 

(20) 

DF14 

Vehicle  movement  rates,  terrain  type  2, 

Red  force. 

c. 

Output 

Variables: 

Name 

Destination 

Contents 

EVTAB 

(7) 

DF11 

Area  holding  a  seven-word  pending  supply  action 
entry. 

SUPREC 

(10) 

DF31 

Area  holding  a  ten-word  supply  status  record. 

BO  (3) 

DF11 

Area  holding  a  three-word  backorder  record. 

NOEVNT 

DF11 

Number  of  pending  supply  action  entries  to  be 
considered  on  next  update  cycle. 

NEMPTY 

DF11 

Pointer  to  start  of  supply  action  file  on  DF11. 

NSIZE 

DF11 

Pointer  to  end  of  supply  action  file  on  DF11. 

BOCHG 

TWO 

Variable  used  in  subroutine  BOFILE. 
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Name 

Destination 

Contents 

BOCORE 

TWO 

Variable 

used 

in 

subroutine 

BOFILE. 

SUPCHG 

TWO 

Variable 

used 

in 

subroutine 

SUPFILE. 

SUPCRE 

TWO 

Variable 

used 

in 

subroutine 

SUPFILE. 

EVTCHG 

TWO 

Variable 

used 

in 

subroutine 

EVTFILE. 

EVTCM 

TWO 

Variable 

used 

in 

subroutine 

EVTFILE. 

TOUT  (256) 

ONE 

Period  history 

■  tape  records 

• 

d. 

Working  Arrays.  The 

event  table 

(EVTBLE) 

and  unit 

identification 

table  (UIDTAB)  are  temporarily  stored  on  data  file  36  permitting  6000  words 
of  Common  TWO  to  be  used  for  working  arrays.  Each  working  array  is 
described  below. 

(1)  Backorder  Constraints,  B0C2(1700).  This  array  contains  the 
constraint  factors  associated  with  unfilled  backorders  contained  on  data 
file  11.  The  first  constraint  factor  is  associated  with  the  first  backorder 
on  data  file  11;  the  second  constraint  factor  is  associated  with  the  second 
backorder  on  data  file  11,  and  so  forth.  Between  update  cycles,  those 
constraint  factors  associated  with  unfilled  Class  I  orders  are  stored  on 
data  file  11. 

(2)  Accumulated  Losses,  AMT1C2(201).  This  array  contains  the 
accumulated  losses  for  each  major  end  item  and  personnel  for  all  front-line 
maneuver  units.  The  number  on  order  of  an  end  item  and  the  current  number 
on  hand  are  substracted  from  the  authorized  level  of  that  item.  This 
difference  is  the  value  accumulated  by  item  over  all  frontline  maneuver  units. 

(3)  Accumulated  Losses,  AMT2C2(201).  This  array  contains  the 
accumulated  losses  for  all  artillery  units  and  maneuver  units  which  are  not 
front  line. 

(4)  Accumulated  Losses,  AMI3C2 (201) .  This  array  contains  the 
accumulated  losses  for  all  units  which  are  neither  maneuver  nor  artillery 
units. 

(5)  Consumption  Array,  C0NSM2 (2560) .  This  array  contains  11  entries 
for  each  of  the  201  equipment  items  (including  personnel)  contained  in  each 
unit  (2211  words  are  used).  The  C0NSM2  array  is  stored  on  data  file  11  be¬ 
tween  update  cycles.  The  11  entries  for  each  item  are: 

(a)  Words  1-9.  Equipment  item  codes  of  transport  vehicles  for 
each  of  nine  distribution/preference  combinations  in  the  following  order. 

.  Unit  distribution,  first  preference 

.  Unit  distribution,  second  preference 


IV-16-B-3 


.  Unit  distribution,  third  preference 
.  Supply  point  distribution,  first  preference 
.  Supply  point  distribution,  second  preference 
.  Supply  point  distribution,  third  preference 
.  Airlift,  first  preference 
.  Airlift,  second  preference 
.  Airlift,  third  preference 

(b)  Word  10.  Unit  weight  of  consumable. 

(c)  Word  11.  Unit  volume  of  consumable. 

(6)  Backorder  Flag  Array,  IFDB02(425).  This  array  contains  flags  to 
indicate  which  of  1700  backorders  will  be  passed  to  the  next  Combat  Service 
Support  update  cycle.  It  is  handled  in  SERSUP  as  a  1700-character  array.  This 
array  is  stored  on  data  file  11  between  update  cycles. 

(7)  Zero  Block,  ZER0(512).  These  locations  are  filled  with  zeros  in 
SERSUP  for  filling  various  arrays  used  in  the  SERSUP  routine  with  zero  entries. 

e.  Logical  Flow: 

(1)  Blocks  1  through  9  (Figure  IV-16-B-1),  Initialization.  The  first 
nine  blocks  initialize  the  SERSUP  routine.  Aircraft  on  missions  are  returned 
to  their  airbases  for  the  update  cycle,  and  they  will  be  put  back  in  the 
mission  units  after  the  update.  A  call  to  routine  MISOUT  performs  these 
functions.  The  parameters  which  intialize  the  input/output  routines,  EVTFIL, 
SUPFIL,  and  BOFILE,  are  set,  as  are  the  switches  specifying  times  of  resupply 
for  Class  I,  personnel,  and  major  end  items.  The  table  giving  the  mobility 
classes  of  each  equipment  item  is  read  from  data  file  9,  and  a  test  is  made 
to  determine  if  the  Class  I,  personnel,  and  major  end  items  should  be  resup¬ 
plied  during  the  current  update  cycle.  If  so,  appropriate  switches  are  set. 
Other  necessary  data  are  brought  into  core,  including  the  parameter  NOEVNT, 
which  specifies  the  number  of  supply  action  events  that  are  pending.  The 
contents  of  EVTBLE  and  VIDTAB  are  saved  on  data  file  36. 

(2)  Blocks  10  through  20  (Figure  IV-16-B-2),  Pending  Supply  Actions. 
These  blocks  describe  the  logic  which  occurs  in  processing  supply  action 
entries.  There  are  five  major  supply  actions  processed: 

.  Arrival  of  consumables  and  loaded  trucks  at  the  receiving 
unit  under  unit  distribution  (INDEX1  *  1) 

.  Arrival  of  the  empty  trucks  back  at  the  supply  point  under 
unit  distribution  after  delivery  of  supplies  (INDEX1  *  3) 


IV-16-B-4 


® 


Figure  IV-16-B-1. 


Combat  Service  Support  Model  Initialization 


IV-16-B-5 


Figure  IV-16-B-2.  Pending  Supply  Actions  (Continued) 
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Figure  IV-16-B-2.  Pending  Supply  Actions  (Continued) 
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Figure  IV-16-B-2 


Pending  Supply  Actions  (Continued) 
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.  Arrival  of  supplies  and  the  transporters  at  the  receiving 
unit  under  supply  point  distribution  (INDEX1  *  4) 

.  Arrival  of  the  empty  trucks  at  the  supply  point  to  pick  up 
the  order  under  supply  point  distribution  (INDEX1  =*  2) 

.  Arrival  of  personnel  and  major  end  items  at  their  destinations 
(INDEX1  =5). 

(a)  Blocks  10  through  12.  A  supply  action  entry  is  first  exam¬ 
ined  to  determine  if  current  time  exceeds  the  time  the  supply  action  was  to 
occur.  If  it  does,  the  action  is  processed;  otherwise,  it  is  held  until  the 
next  Combat  Service  Support  update  cycle.  After  all  pending  supply  actions 
are  examined,  resupply  orders  for  critical  consumables  and  expendables  are 
created  and  available  transportation  assigned. 

(b)  Blocks  13  and  14.  These  blocks  describe  the  logic  when 
INDEX1  =1,  the  action  when  trucks  loaded  with  consumables  arrive  at  the 
receiving  unit  under  unit  distribution.  The  consumables  are  added  to  the 
receiving  unit's  trains  on  data  file  31.  The  empty  trucks  are  given  INDEX1  =  3, 
and  the  time  of  their  return  to  the  supply  point  is  scheduled. 

(c)  Blocks  15  through  17.  These  blocks  describe  the  logic  when 
INDEX1  *  +  2,  the  supply  action  which  is  the  arrival  of  empty  trucks  from  the 
receiving  unit  at  the  supply  point  with  an  order  for  supplies  under  supply 
point  distribution.  If  INDEX1  *  -2,  the  supply  point  is  an  ultimate  supply 
point  and  the  supplies  are  added  to  the  ultimate  supply  point.  If  INDEX1  *  +2, 
the  supply  point  is  an  intermediate  supply  point  and  the  required  supplies  are 
subtracted  from  the  supply  point.  Supply  actions  are  scheduled  for  the  arrival 
of  the  supplies  and  for  the  trucks  returning  to  the  receiving  unit.  In  both 
cases  INDEX1  is  set  equal  to  4. 

(d)  Block  18.  This  block  describes  the  logic  when  INDEX1  =3, 
the  arrival  of  the  empty  trucks  at  the  supply  point  after  they  have  delivered 
supplies  under  unit  distribution. 

(e)  Block  19.  This  block  describes  the  logic  when  INDEX1  «■  4, 
the  arrival  of  loaded  trucks  at  the  receiving  unit  under  supply  point 
distribution.  The  trucks  are  added  to  the  receiving  unit's  status  record  on 
data  file  1;  the  consumables  are  added  to  the  receiving  unit's  trains  on  data 
file  31. 

(f)  Block  20.  This  block  describes  the  logic  when  INDEX1  ■  5, 
the  arrival  of  personnel  replacements  and  major  end  item  replenishments  at 
their  destinations.  These  items  are  added  directly  to  the  receiving  unit's 
status  record. 

(3)  Blocks  21  through  39  (Figure  IV-16-B-3),  Force  Loop.  Both  second 
and  third  major  loops  of  the  Combat  Service  Support  Model  are  executed  first 
for  the  Blue  force  and  then  for  the  Red  force.  Blocks  21  through  26  initial¬ 
ize  the  second  major  loop.  Weight  and  volume  capacities  of  the  transport 
vehicles  are  brought  into  core.  If  personnel  and  major  end  items  are  to  be 
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replaced  during  this  update  cycle,  appropriate  arrays  are  filled  with  zeros. 

The  IUID's  of  maneuver  units  which  are  considered  to  be  on  the  front  line  of 
the  battlefield  are  read  from  data  file  16.  The  backorder  counter  for  Class  I 
resupply  is  initialized  to  zero.  Blocks  27  through  39  show  the  second  major 
loop.  Blocks  27  through  34  show  the  creation  of  backorders  for  critical 
consumables  and  expendables.  Blocks  35  through  39  show  the  filling  of  these 
orders  and  the  assignment  of  available  transportation.  This  second  major 
loop  is  processed  first  for  front-line  maneuver  units,  then  for  artillery  and 
any  other  maneuver  units,  and  finally  for  all  other  units. 

(a)  Block  27.  This  block  depicts  the  logic  of  selecting  a  unit 
for  processing.  Each  unit  is  checked  to  determine  if  it  is  resolution.  If  it 
is  not,  the  next  candidate  unit  is  examined.  A  check  is  also  made  to  ensure 
that  the  selected  unit  is  not  currently  being  airlifted.  If  it  is,  resupply 
is  delayed  until  the  airlift  is  completed. 

(b)  Block  28.  After  a  particular  unit  has  been  selected,  each 
equipment  item  in  the  unit  is  examined  to  determine  if  it  need  be  resupplied. 

(c)  Block  29.  If  the  item  examined  is  Class  I,  a  check  is  made 
to  determine  if  it  is  time  to  reorder  Class  I.  If  it  is  not  the  next  item  of 
this  unit  is  selected  and  examined.  If  it  is  reorder  time,  then  a  Class  I 
backorder  is  generated.  The  next  item  is  then  selected. 

(d)  Block  30.  If  the  item  examined  is  personnel  or  a  major  end 
item,  a  check  is  made  to  determine  if  it  is  time  to  reorder.  If  it  is  not, 
the  next  item  is  selected.  If  it  is  reorder  time,  the  unit  is  examined  to  see 
if  it  is  an  airbase.  If  it  is  not,  and  the  equipment  item  is  an  aircraft 
which  is  out  on  a  mission,  no  resupply  of  this  item  occurs.  If  the  item  should 
be  reordered,  the  flow  goes  to  block  31. 

(e)  Block  31.  Before  an  order  is  issued  for  a  consumable,  a 
major  end  item,  or  personnel,  a  determination  is  made  of  the  amount  of  the 
item  that  is  currently  on  order.  This  on-order  quantity  is  considered  in 
calculating  the  amount  of  an  Item  to  reorder. 

(f)  Block  32.  If  the  candidate  item  is  personnel  or  a  major 
end  item,  the  reorder  quantity  which  is  needed  is  stored  on  data  file  11  and 
the  next  equipment  item  is  selected, 

(g)  Block  33.  If  the  equipment  item  being  examined  is  a 
consumable  or  expendable,  the  quantity  on  trains  is  moved  to  the  equipment 
on  hand  array  on  the  unit’s  status  record  to  the  extent  that  the  unit  is 
brought  up  to  its  authorised  levels. 

(h)  Block  34.  This  section  of  logic  creates  the  backorder  for 
a  single  consumable  or  expendable.  The  quantity  of  the  backorder  is  calcu¬ 
lated.  A  maximum  of  1700  backorders  can  be  created.  If  this  limit  was  not 
reached,  the  backorder  is  stored  on  file  11;  otherwise,  the  backorder  is 
lost  and  must  be  created  on  the  next  cycle. 
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(i)  Block  35.  The  backorder  with  highest  priority  is  selected 
and  the  corresponding  supply  status  file,  data  file  31,  entry  is  obtained. 

The  supplier  unit  and  supplied  unit  status  records  are  brought  into  core  from 
the  data  file  1.  The  weight  and  volume  requirements  of  the  consumable  as  well 
as  the  weight  and  volume  capacities  of  available  transport  vehicles  are  brought 
into  core. 


(j )  Block  36.  At  this  point  the  backorder  is  filled  if  possible, 
and  transportation  is  assigned.  Three  distribution  methods  are  possible: 

unit  distribution,  supply  point  distribution,  and  airlift.  Three  transport 
vehicle  types  can  be  used  under  each  distribution  method.  If  the  unit  needing 
the  order  is  in  enemy  territory,  only  airlift  is  attempted;  otherwise,  all 
three  methods  can  be  tried  if  the  demand  for  a  consumable  is  great  enough. 

The  constraint  factor  associated  with  the  backorder  must  have  a  value  less 
than  0.8  before  the  second  ground  distribution  method  will  be  attempted,  and 
a  value  less  than  0.5  before  airlift  will  be  used.  The  value  of  the  constraint 
factor  is  inversely  proportional  to  the  demand  for  the  consumable. 

(k)  Block  37.  If  the  backorder  was  for  Class  I  and  only  a 
partial  order  could  be  satisfied,  a  new  backorder  is  created  for  the  remaining 
quantity  and  stored  on  data  file  11  until  the  next  Combat  Service  Support 
update  cycle. 


(l)  Block  38.  A  check  is  made  to  determine  if  there  are  other 
backorders  to  be  processed.  If  there  are,  then  blocks  35  through  38  are 
repeated.  Otherwise,  requirements  of  personnel  replacements  and  replenishment 
of  major  end  items  are  stored  on  data  file  11.  Backorder  and  constraint 
facotrs  for  Class  I  are  also  stored  on  data  file  11. 

(m)  Block  39.  At  this  point,  a  check  is  made  to  determine  if 
major  end  items  and  personnel  are  to  be  updated  during  this  cycle.  If  not,  a 
check  is  made  to  determine  if  the  Red  force  is  being  processed.  If  both  tests 
are  negative,  control  returns  to  block  21.  If  only  the  second  test  is  negative 
(i.e.,  the  Blue  force  is  being  processed),  subroutine  MISOUT  is  called  to 
place  aircraft  back  in  their  mission  units.  The  buffer  files  are  emptied, 

the  event  and  unit  identification  table  restored,  and  the  next  Combat  Service 
Support  update  cycle  is  scheduled.  If  it  is  time  for  resupply  of  personnel 
and  major  end  items,  control  goes  to  block  40. 

(4)  Blocks  40  through  47  (Figure  IV-16-B-4),  Personnel  an»'.  Major  End 
Item  Resupply.  These  blocks  show  the  third  and  final  loop  of  the  Combat 
Service  Support  Model.  Supply  action  entries  are  created  for  personnel  and 
major  end  items  in  this  loop.  This  loop  is  executed  three  time.  First,  it 
is  executed  for  all  front-line  maneuver  units,  then  for  all  artillery  units 
and  other  maneuver  units,  and  finally  for  all  other  units. 

(a)  Block  40.  This  block  is  the  beginning  of  the  personnel 
and  major  end  item  resupply  loop.  Numbers  of  personnel  and  major  end  items 
available  for  resupply  on  the  day  being  considered  are  brought  into  core  from 
data  file  11.  Next,  one  of  the  three  unit  groups  is  selected. 
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Figure  IV-16-B-4.  Personnel  and  Malor  End  Items  Resupply  (Continued) 
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Figure  IV-16-B-4.  Personnel  and  Major  End  Items  Resupply  (Concluded) 
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(b)  Block  41.  The  total  losses  by  item  for  this  unit  group  is 
obtained  from  the  appropriate  accumulated  loss  array.  A  unit  is  then  selected 
from  the  given  unit  group. 

(c)  Block  42.  The  selected  unit's  loss  record  of  personnel  and 
major  end  items  is  obtained  from  data  file  11.  An  item  is  selected  from  the 
unit;  and,  if  it  is  a  major  end  item  or  personnel,  the  following  logic  is  used. 
If  it  is  neither  of  the  above,  then  the  next  item  in  the  unit  is  examined. 

(d)  Block  43.  It  the  item  is  available  for  resupply,  the 
quantity  to  be  delivered  (full  or  prorated)  is  determined.  The  quantity 
ordered  is  subtracted  from  the  total  given  in  the  AVAIL  table.  Transfer  time 
for  the  vehicles  to  deliver  major  end  items  is  determined. 

(e)  Block  44.  If  all  items  have  been  processed  for  the  unit, 
the  unit  needs  array  is  zeroed  out.  If  not,  the  next  item  is  selected. 

(f)  Block  45.  If  this  is  not  the  last  unit  in  this  group  the 
next  unit  is  selected  and  control  goes  to  block  42. 

(g)  Block  46.  If  this  is  not  the  last  unit  group,  the  next  unit 
group  is  selected  and  the  flow  returns  to  block  41. 

(h)  Block  47.  Finally,  the  available  personnel  and  major  end 
items  not  used  will  be  rolled  into  the  next  day's  AVAIL  table.  The  backorder 
constraints  are  stored  on  data  file  11. 

3.  ROUTINE  TRNTIM: 

a.  Purpose.  This  routine  calculates  the  time  in  minutes  required  for  a 
given  vehicle  to  travel  between  two  units. 

b.  Input  Variables: 


(1) 

Standard  Common 

Block  Areas.  BPOINT  and  UNTL0C. 

(2) 

Other  Variables: 

Name 

Source 

Contents 

MCLASB 

(200) 

TWO 

Mobility  classes  of  Blue  force  equipment. 

MCLASR 

(200) 

TWO 

Mobility  classes  of  Red  force 

equipment. 

IRAT1B 

(20) 

TWO 

Vehicle  movement  rates  versus 
Blue  force,  terrain  type  1. 

mobility  classes, 

IRAT2B 

(20) 

TWO 

Vehicle  movement  rates  versus 
Blue  force,  terrain  type  2. 

mobility  classes, 

IRATE 1 

(20) 

TWO 

Vehicle  movement  rates  versus 
Red  force,  terrain  type  1. 

mobility  classes, 
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Name 

Source 

Contents 

IRATE2 

(20) 

TWO 

Vehicle  movement  rates  versus  mobility  classes, 
Red  force,  terrain  type  2. 

11,  12 

TWO 

lUIDs  of  units  between  which  vehicle  is 
traveling. 

LEOH 

Call 

Equipment  item  code  of  vehicle  for  which 
travel  time  is  being  calculated. 

c. 

Output  Variables: 

Name 

Destination 

Contents 

ITIME 

Call 

Travel  time  (minutes). 

d.  Logical  Flow  (Figure  IV-16-B-5): 

(1)  Block  1.  Get  the  X  and  Y  coordinates  of  the  two  units  between 
which  the  vehicle  is  traveling  from  UNTLOC. 

(2)  Block  2,  Calculate  the  distance  in  meters  between  the  two  units 
using  the  function  RANGEF. 

(3)  Block  3.  Get  mobility  class  of  the  vehicle  for  the  appropriate 

force. 

(4)  Block  4.  If  the  mobility  class  is  invalid,  the  travel  time  is 
set  equal  to  zero  and  control  is  returned  to  the  calling  program. 

(5)  Block  5.  Calculate  the  averpge  velocity  of  the  vehicle  over  the 
two  terrain  types  for  travel  over  an  asphalt-surfaced  road. 

(6)  Block  6.  Calculate  the  travel  time. 

4.  ROUTINE  EVTFIL : 

a.  Purpose.  This  routine  handles  all  input/output  operations  >n  supply 
action  entries  which  are  stored  on  data  file  11  beginning  in  record  249.  To 
increase  the  speed  and  efficiency  of  the  Combat  Service  Support  Model  this 
routine  uses  a  buffering  scheme  which  allows  70  supply  action  entries  to  be 
accessed  simultaneously.  A  maximum  of  70  supply  action  entries  are  placed 
on  a  record  of  512  words  (i.e.,  70  x  7  ■  490  words).  When  a  supply  action 
entry  is  addressed,  a  block  of  70  entries  is  brought  into  a  buffer  area 
4  called  EVTVEC.  After  the  particular  event  being  considered  is  located,  the 
seven-word  entry  is  moved  to  a  word  area  labeled  EVTAB. 
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Figure  IV-16-B-5.  Routine  TRNTIM 


b.  Input  Variables: 


Name 

Source 

Contents 

IREC 

Call 

Relative  location  on  data  file  11  of  the 
pending  supply  action  being  processed. 

10 

Call 

Type  operation  to  be  performed: 

10  =  1,  input 

10  =  2,  output 

10  =  3,  final  output,  clear  buffer 

EVTCM 

TWO 

Switch  indicating  whether  a  new  490-word 
block  needs  to  be  buffered  into  or  out  of  the 
buffer  area. 

EVTCHG 

TWO 

Switch  indicating  whether  last  operation  was 
input  or  output: 

EVTCHG  -  0,  input 

EVTCHG  =  1,  output 

c. 

Output  Variables: 

Name 

Source 

Contents 

EVTVEC 

(490) 

TWO 

Buffer  area  containing  70  seven-word  supply 
action  events. 

EVTAB 

(7) 

TWO 

Work  area  containing  a  single  supply  action 
entry. 

EVTIM 

EVTAB (1)  Time  entry  is  due  to  be  updated, 
time  =  0  denotes  empty  entry. 

.  UNITI 

EVTAB(2)  IUID  of  unit  generating  order. 

RECNO 

EVTAB(3)  Record  number  on  data  file  31,  supply 
status  file. 

KEOH 

* 

EVTAB (4)  Equipment  item  code:  if  positive, 
item  being  ordered;  if  negative,  transporting 
vehicle. 

QUAN 

EVTAB ( 5 )  Quantity  being  shipped. 

*  UNIT2 

EVTAB (6)  IUID  of  supply  point. 

INDEX1 

EVTAB(7)  Index  flag  (1  through  4  or  -2). 

( 
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d.  Logical  Flow  (Figure  IV-16-B-6) : 

(1)  Block  1.  If  this  is  a  final  output  and  the  last  operation  was 

an  input  task,  the  buffer  area  is  put  back  on  data  file  11. 

(2)  Block  2.  If  this  is  not  a  final  output  operation,  the  appropriate 

490-word  block  on  data  file  11  is  determined. 

(3)  Block  3.  If  the  desired  block  is  in  the  buffer  area  and  an  input 
operation  is  being  performed,  the  supply  action  entry  is  moved  from  the  buffer, 
EVTVEC,  to  the  work  area,  EVTAB.  If  thr  desired  490-word  block  is  in  the 
buffer  area  and  an  output  operation  is  being  performed,  EVTAB  is  moved  to 
EVTVEC. 


(4)  Block  4.  If  the  desired  490-word  block  is  not  in  the  buffer  area, 
a  check  is  made  to  determine  if  the  last  operation  was  an  output.  If  not,  the 
contents  of  the  buffer  area  are  placed  on  data  file  11. 

(5)  Block  5.  In  any  case,  a  new  490-word  block  is  read  into  the 
buffer  area  and  the  appropriate  switches  set.  The  pending  supply  action  entry 
is  moved  from  the  buffer  area  into  EVTAB. 

5.  ROUTINE  SUPFIL: 

a.  Purpose.  This  routine  handles  all  maintenance  input /output  operations 
on  the  supply  status  file,  data  file  31.  To  increase  the  speed  and  efficiency 

of  the  Combat  Service  Support  Made 1,  this  routine  uses  a  buffer  area  which 

allows  50  supply  status  entries  to  be  obtained  with  one  disk  access.  A 
maximum  of  50  supply  status  entries  are  placed  on  a  record  of  512  words  (i.e., 

50  x  10  =  500  words).  When  a  supply  status  entry  is  addressed,  a  block  of  50 

entries  is  brought  into  a  buffer  area  called  SUPVEC  (500).  After  the  particular 
record  being  considered  is  found,  the  10-word  entry  is  moved  to  a  work  area 
labeled  SUPREC. 


b.  Input  Variables: 


Name 

Source 

Contents 

IREC 

Call 

The  relative  location  on  data  file  31  of  the 
supply  status  record  to  be  updated. 

10 

Call 

The  operation  type  to  be  performed: 

10  *  1 ,  input 

10  •  2,  output 

10  -  3,  final  output,  clear  buffer 

SUPCRE 

TWO 

A  pointer  to  indicate  if  a  new  500-word  block 

(50  entries  x  10  words  per  entry)  need  be 
buffered  into  or  out  of  the  buffer  area  SUPVEC 
(500). 
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Maine 


Source 


Contents 


SUPCHG 

TWO 

A  pointer  to  indicate  if  last  operation  was 
input  or  output: 

SUPCHG  -  0,  input 

SUPCHG  «  1,  output 

c. 

Output 

Variables: 

Name 

Destination 

Contents 

SUPVEC 

(500) 

TWO 

Buffer  area  which  holds  50  10-word  supply 
status  records. 

SUPREC 

(10) 

TWO 

A  work  area  which  contains  a  single  supply 
status  record. 

JEOH 

SUPREC(l)  Equipment  item  code  (1-201) 

ACV 

SUPREC (2)  Authorized  on  combat  vehicles. 

AOHT 

SUPREC(3)  Authorized  on  hand  trains. 

OHT 

SUPREC (4)  On  hand  trains. 

RATUSE 

SUPREC (5)  Usage  rate  (biased  by  1000). 

SIGMA 

SUPREC (6)  Sigma  (biased  by  100). 

INDEX2 

SUPREC (7)  Index  flag: 

1  *  unit  distribution 

2  =  supply  point 

ASR 

SUPREC (8)  Number  of  major  end  items  or  personnel 
replacements. 

CONST 

SUPREC (9)  Backorder  constraint  factor  (biased 
by  100). 

SUPDEL 

SUPREC (10)  Not  used. 

d.  Logical  Flow  (Figure  IV-16-B-7) : 


(1)  Block  1,  Determine  If  this  is  a  final  output  task.  If  it  is, 
and  the  last  operation  was  an  input,  the  buffer  area  is  put  back  on  data 
file  31. 

(2)  Block  2.  If  this  is  not  a  final  output  task,  the  next  500-word 
block  that  is  to  be  buffered  in  is  determined. 
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Figure  IV-16-B-7.  Routine  SUPFIL 
IV-16-B-31 


(3)  Block  3.  If  the  desired  block  is  in  the  buffer  area  and  an  input 
operation  is  being  performed,  the  supply  status  record  is  moved  from  the  buffer, 
SUPVEC,  to  the  work  area,  SUPREC.  If  the  desired  500-word  block  is  in  the 
buffer  area  and  an  output  operation  is  being  performed,  SUPREC  is  moved  to 
SUPVEC. 

(4)  Block  4.  If  a  new  500-word  block  is  required,  it  is  read  into 
SUPVEC.  Before  the  record  is  read,  a  check  is  made  against  the  file  name 
table  so  that  the  read  will  not  exceed  the  size  of  data  file  31.  This  is 
required  since  new  data  file  31  records  are  sometimes  created  when  units  are 
joined  or  detached  from  one  another. 

(5)  Block  5.  When  a  500-word  block  is  put  back  on  data  file  31,  a 
check  is  again  made  to  ensure  that  the  size  of  data  file  is  not  exceeded. 

6.  ROUTINE  BOFILE: 

a.  Purpose.  This  routine  handles  all  input/output  operations  of  the 
backorder  files.  For  the  Blue  force,  the  backorder  files  are  the  first  10 
records  of  data  file  11.  For  the  Red  force,  the  backorder  file  is  records 
11  through  20.  Each  entry  on  the  file  consists  of  three  words  (see  BO  array 
above).  For  each  backorder  entry,  a  corresponding  constraint  factor  is 
stored  in  the  BOC2  array.  This  routine  uses  a  buffering  scheme  which  allows 
170  backorder  entries  to  be  obtained  with  one  disk  access.  Up  to  170  entries 
are  placed  on  a  record  of  512  words  (i.e.,  170  x  3  ■  510  words). 

b.  Input  Variables: 


Name 

Source 

Contents 

IREC 

Call 

Specifies  the  relative  location  within  the 
1700  possible  backorders  on  data  file  11  of 
the  desired  3-word  backorder. 

IO 

Call 

Indicates  operation  type: 

IO  *  1,  input 

10  ■  2,  output 

IO  ■  3,  final  output 

B0C0RE 

TWO 

Indicates  whether  a  new  510-word  block 
(170  x  3)  need  be  buffered  in  or  out  of 
the  buffer  area. 

BOCHG 

TWO 

Switch  to  determine  if  last  operation  input 
or  output: 

BOCHG  ■  0,  input 

BOCHG  ■  1,  output 
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c.  Output  Variables: 


Name 

Destination 

Contents 

BOVEC (510)  TWO 

Buffer  area  which  holds  170  three-word 
backorder  entries. 

B0(3) 

TWO 

A  work  area  which  contains  a  single  backorder 
entry,  BO. 

BOUNIT 

B0(1)  IUID  of  unit  issuing  order. 

BOEOH 

B0(2)  Cross  reference  record  on  data  file  31. 

BOQUAN 

B0(3)  Quantity  backordered. 

d.  Logical  Flow  (Figure  IV 
of  EVTFIL  and  SUPFIL. 

-16-B-8).  The  logical  flow  is  similar  to  that 

7.  ROUTINE  FETCH: 

a.  Purpose.  This  routine 
physical  record  on  data  file  11 

obtains  a  logical  record  from  more  than  one 

• 

b. 

Input  Variables: 

Name 

Source 

Contents 

10 

Call 

Switch  to  indicate  if  operation  is  to  be  input 
or  output: 

10  »  0,  input 

10  ■  1,  output 

LOGREC 

Call 

Relative  location  of  logical  record  under 
consideration  within  the  physical  record. 

LOCAV 

Call 

Location  in  core  that  information  will  be 
transferred  into  or  from. 

NREC 

Call 

Physical  record  where  first  logical  record  of 
the  desired  type  will  be  found. 

ILCON 

Call 

Number  of  words  per  logical  record. 

IPCON 

Call 

Number  of  words  per  physical  record. 

c. 

Output  Variables: 

Name 

Destination 

Contents 

LOCAV 

Call 

Array  that  information  will  be  transferred 

into  or  from. 

c 
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d.  Description.  When  this  program  is  entered,  it  is  determined  whether 
the  desired  logical  record  lies  on  more  than  one  physical  record.  If  it  does, 
two  calls  are  made  to  the  appropriate  input/output  routine;  otherwise,  only 
one  call  is  made.  If  the  operation  is  input,  subroutine  GETWRD  is  called. 

If  the  operation  is  output,  subroutine  PUTWRD  is  called. 

8.  ROUTINE  MISOUT: 

a.  Purpose.  This  routine  prevents  the  Combat  Service  Support  Model  from 
resupplying  aircraft  to  an  airbase  unit  when  the  missing  aircraft  are  on  a 
«  mission  during  a  resupply  cycle.  At  the  beginning  of  a  resupply  cycle,  these 
aircraft  are  subtracted  from  the  mission  unit  and  added  to  the  airbase  unit. 
When  the  resupply  cycle  is  complete,  the  aircraft  are  removed  from  the  airbase 
unit  and  placed  on  the  mission  units. 


b.  Input  Variables: 


UTDTAB. 

(1) 

Standard  Common 

Block  Areas.  UMAIN,  UCOOP,  BPOINT,  UNTLOC,  and 

(2) 

Other  Variables: 

Name 

Source 

Contents 

F 

Call 

Switch  Indicating  whether  mission  unit  air¬ 
craft  are  added  to  or  subtracted  from  their 
respective  airbases: 

F  -  1,  add 

F  »  -1,  subtract 

ITRNAB 

ONE 

Airbase  to  which  the  transport  aircraft  belong 

ITEIC 

ONE 

Equipment  item  code  of  transport  aircraft. 

ICRTAB 

ONE 

Airbase  to  which  the  escort  aircraft  belong. 

ICREIC 

ONE 

Equipment  item  code  of  escort  aircraft. 

c.  Output  Variable.  None. 

d.  Logical  Flow  (Figure  IV-16-B-9) : 

(1)  Block  1.  Find  a  resolution  air-mission  unit. 

(2)  Block  2.  Determine  if  this  air-mission  unit  has  any  escort 
4  aircraft. 

(3)  Block  3.  If  the  air-mission  unit  has  escort  aircraft,  add 
(or  subtract)  aircraft  to  (or  from)  appropriate  airbase.  A  check  is  then 
made  to  determine  if  the  mission  unit  has  transport  aircraft. 
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(4)  Block  4.  Does  the  air  mission  unit  have  transport  aircraft?  If 
it  does,  these  aircraft  are  added  to  (subtracted  from)  the  appropriate  airbase 
unit. 


(5)  Block  5.  If  there  are  other  air  mission  units,  go  to  block  2 
and  examine  the  new  unit. 


9.  ROUTINE  RESLVE: 


a.  Purpose.  This  routine  determines  if  a  given  unit  is  resolution. 

b.  Input  Variables: 

(1)  Standard  Common  Block  Areas.  UMAIN,  UCOOP. 

(2)  Other  Variables: 


Name  Source 

I  Call 


KUID  Call 

c.  Output  Variables: 
Name  Destination 

J  Call 


Contents 


Indicator  which  specifies  if  unit  status  record 
is  in  UMAIN  or  UCOOP: 

1=0,  UMAIN 
1=1,  UCOOP 

IUID  of  unit  which  is  under  test. 


Contents 


Indicator  which  specifies  if  unit  was  found 
to  be  resolution: 

J  ■  0,  resolution 
J  *  1,  nonresolution 


d.  Logical  Flow  (Figure  IV-16-B-10) .  After  it  is  determined  whether  the 
unit  status  record  is  in  UMAIN  or  UCOOP,  the  coordinates  of  the  unit  are 
checked  to  determine  if  they  are  non-zero.  If  either  the  X  or  Y  coordinate 
is  non-zero,  the  unit  is  resolution.  A  check  is  made  to  determine  if  this 
resolution  unit  has  a  supply  status  record  on  data  file  31.  If  a  supply 
status  record  exists,  J  returns  to  SERSUP  with  a  value  of  zero.  If  no  data 
file  31  record  exists,  J  returns  with  a  value  of  one.  If  the  unit  is  non- 
resolution,  a  check  is  made  to  determine  if  the  unit  has  a  superior.  If  it 
does  not,  J  returns  with  a  value  of  one.  If  a  superior  unit  is  present, 
this  unit  is  also  checked  for  resolution. 

10.  ROUTINE  CSSANL: 


a.  Purpose.  This  routine  prepares  the  analysis  output  record  for 
supply  action  events  and  calls  PUTOUT  to  place  the  record  on  the  period 
history  tape. 
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b.  Input  Variables: 

(1)  Standard  Common  Block  Areas:  DAY,  HOUR,  MINUTE 

(2)  Other  Variables: 


Name 

Source 

Contents 

EVTAB (7) 

TWO 

Refer  to  EVTFIL 

I 

Call 

Action  entry  in  or  out  flag: 

1*1,  supply  action  being  processed 
I  *  2,  supply  action  being  scheduled 

c.  Output  Variable: 

Name 

Destination 

Contents 

IOUT (256) 

ONE 

Analysis  output  record. 

d.  Logical  Flow  (Figure  IV-16-B-11) .  The  game  time  and  record  type  code 
(521)  are  placed  In  the  first  two  words  of  IOUT.  The  contents  of  EVTAB  are 
moved  to  the  appropriate  words  of  IOUT.  Routine  PUTOUT  is  called  to  place 
the  record  on  the  period  history  tape. 
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APPENDIX  C 


COMBAT  SERVICE  SUPPORT  MODEL  OUTPUT  DESCRIPTIONS 


This  appendix  contains  a  detailed  description  of  printed  output  from 
routine  SERSUP  within  the  Combat  Service  Support  Model  of  the  Period  Processor. 
Figure  IV-16-C-1  depicts  the  format  of  the  printout.  In  the  figure,  each 
line  preceded  by  the  number  symbol  (#)  is  not  keyed  to  a  sense  switch;  all 
other  lines  are  keyed  to  sense  switch  3.  An  alphabetical  character  (descriptor) 
designates  an  appropriate  line,  group  of  lines,  or  column  in  the  figure  that 
is  explained  as  follows. 


Output 

Descriptor 


A 

B 


C 


D 


Explanation 

This  entry  appears  at  the  start  of  each  Combat  Service 
Support  cycle  and  serves  as  an  identification. 

These  entries  give  the  game  time  and  the  status  of  the  event 
file,  data  file  11. 

GAMTIM:  minutes  since  start  of  period 

NOEVNT:  number  of  pending  supply  action  events  to  be  processed 
(stored  on  data  file  11). 

NEMPTY:  pointer  to  starting  location  in  pending  action  event 
file  of  events  to  be  processed. 

NSIZE:  pointer  to  ending  location  of  pending  action  event 
file. 

This  type  entry  appears  for  each  unit  that  is  to  be  resupplied. 
It  is  always  identified  by  asterisks  (*)  in  columns  two 
through  five.  Three  numbers  are  printed  in  this  entry'.  The 
first  is  the  unit  identification  record  number  of  the  unit 
being  processed.  The  second  and  third  are  the  start  and 
end  locations,  respectively,  on  data  file  31  of  the  supply 
status  records  for  this  unit. 

This  entry  is  printed  for  each  consumable  that  a  unit  wants 
resupplied.  If  an  entry  does  not  appear  for  an  item,  that 
item  will  not  be  resupplied  for  the  unit.  This  entry 
contains  10  fields  and  consists  of  the  information  stored 
on  the  supply  status  record,  data  file  31.  The  information 
is: 

Field  1,  JEOH:  equipment  item  code  (1-201) 

Field  2,  ACV:  authorized  on  combat  vehicles. 

Field  3,  AOHT:  authorized  on  hand  trains. 


Figure  IV-16-C-1.  Routine  SERSUP  Sample  Output  (Continued 
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WEIGHTS  AHO  VOLUMES 
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Routine  SERSUP  Sample  Output  (Concluded) 


Field  4,  OHT:  on  hand  trains. 

Field  5,  RATUSE:  usage  rate  (biased  by  1000), 

Field  6,  SIGMA:  sigma  (biased  by  100). 

Field  7,  INDEX2:  index  flag;  1  =  unit  distribution,  2  «  supply 
point. 

•  Field  8,  ASR:  number  of  major  end  items  or  personnel  replace¬ 

ments. 

Field  9,  CONST:  backorder  constraint  factor  (biased  by  100). 

Field  10,  SUPDEL:  not  used. 

E  NOBO:  This  indicates  which  backorder  is  being  generated. 

This  number  is  incremented  by  one  for  each  order  within  a 
group  (i.e.,  front-line  maneuver  units). 

F  PUT  BOFILE:  This  entry  will  appear  each  time  the  above  entry 

appears.  It  contains  three  bits  of  information  that  are 
the  unit  identification  record  number  of  the  requesting 
unit,  the  location  of  supply  status  file  record  for  the 
requested  item,  and  the  requested  number  of  units  of  this 
item. 

G  This  entry  is  the  same  as  D,  except  that  D  was  for  food 

and  used  different  logic  than  other  consumables.  Entries 
H  and  I  always  follow  G  entries  except  for  food,  personnel, 
and  major  end  items. 

H  RATE:  usage  rate  for  this  item  this  Combat  Service  Support 

cycle. 

SIG:  variance  in  usage  rate  this  Combat  Service  Support  cycle, 

R9:  accelerated  usage  rate  (see  rq  in  tech  manual). 

DEL:  difference  between  authorized  and  quantity  on  hand. 

OHT:  on  hand  in  trains. 

SUPDEL:  not  used. 

I  This  entry  will  always  follow  G  and  H  entries. 

Q:  projected  outage  indicator,  if  Q  is  less  than  zero, 
order  is  generated. 

RR:  restricted  rate  of  usage. 

«  ASR:  number  of  major  end  item  or  personnel  replacements  by 

type. 

CON:  constraint  factor,  ci. 

QT2:  stock  on  hand  and  in  bulk  plus  stock  on  order 

OHT:  current  amount  of  item  on  hand  in  trains. 

QT:  delivery  lead  time. 
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After  all  items  of  each  unit  of  a  group,  i.e.,  front-line 
maneuver  units,  have  been  processed  and  the  consumable 
requests  generated,  available  transportation  is  assigned. 

This  entry  will  always  appear  as  the  first  entry  to  the 
assignment  logic. 

NOBACK:  This  number  gives  the  total  number  of  requests 
ger.arated  for  this  unit  group.  Entries  K,  L,  and  M  are 
repeated  for  each  request  generated. 

CROSS:  This  is  an  11-word  entry  containing  equipment  item 
code  of  transports  that  will  haul  this  consumable. 

Field  1,  unit  distribution  first  preference. 

Field  2,  unit  distribution  second  preference. 

Field  3,  unit  distribution  third  preference. 

Field  4,  supply  point  distribution  first  preference. 

Field  5,  supply  point  distribution  second  preference. 

Field  6,  supply  point  distribution  third  preference. 

Field  7,  airlift  first  preference. 

Field  8,  airlift  second  preference. 

Field  9,  airlift  third  preference. 

Field  10,  weight  of  consumables. 

Field  11,  volume  of  consumables. 

WEIGHTS  AND  VOLUMES:  This  entry  contains  six  fields  as 

follows : 

Field  1,  total  weight  capacity  of  transports. 

Field  2,  total  weight  of  consumables. 

Field  3,  total  volume  capacity  of  transports. 

Field  4,  total  volume  of  consumables. 

Field  5,  percent  of  available  transport  that  will  be  used  to 
deliver  requested  item. 

Field  6,  percent  of  consumables  that  will  be  delivered. 

PUT  EVTFILE:  This  entry  contains  eight  fields.  The  first 
field  specifies  where  this  information  will  be  stored  on 
data  file  11  starting  with  record  250.  The  last  seven 
fields  will  be  stored  on  data  file  11  and  contain  informa¬ 
tion  reflecting  pending  supply  actions.  These  entries  contain: 

EVTIM:  time  entry  is  due  to  be  updated;  Time»*0  denotes  empty 

entry.  » 

UNIT1,  unit  identification  record  number  of  unit  that  gener¬ 
ated  request. 
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RECNO,  the  supply  status  record  number  (data  file  31)  of  the 
corresponding  equipment  item  code  for  this  unit  (UNIT1). 

KEOH,  equipment  item  code  of  item  being  requested  or  of  vehicle 
being  used  if  equipment  item  code  is  negative. 

QUAN,  quantity  of  requested  order  being  transported. 

UNIT2,  unit  identification  record  number  of  supply  point. 

INDEX2,  flag  indicating  type  of  supply  action  (1-4  or  -2). 

SUPPLY  ACTION  EVTAB:  The  seven  numbers  following  this  title 
are  the  same  as  the  last  seven  that  follow  PUT  EVTFILE 
(see  output  description  M  above) .  The  SUPPLY  ACTION 
EVTAB  line  denotes  the  pending  supply  action  processed  this 
Combat  Service  Support  cycle.  The  PUT  EVTFILE  line  denotes 
the  pending  supply  action  that  will  be  stored  on  data  file  11 
and  processed  on  the  next  Combat  Service  Support  cycle.  If 
EVTIM  »  0,  the  supply  action  has  been  completed.  The  list 
of  pending  supply  actions  to  be  processed  on  the  current 
Combat  Service  Support  cycle  always  appears  immediately 
after  the  COMBAT  SERVICE  SUPPORT  heading. 

ACV:  authorized  quantity  of  preceding  item  (i.e.,  item  39) 
in  readily  usable  status,  authorized  in  combat  vehicles. 

TEOH:  quantity  of  preceding  item  (i.e.,  item  39)  in  readily 
usable  status. 

0N0:  amount  of  item  currently  requested,  possibly  in  transit. 

In  these  instances  the  entry  pertains  to  the  resupply  of  a 
major  end  item  or  personnel.  This  particular  entry  pertains 
to  a  major  end  item,  item  code  88  (see  description  M,  KEOH). 

ACV:  number  of  item  requested  for  resupply. 

TEOH:  percent  of  requested  quantity  that  will  be  issued. 

0N0:  actual  amount  to  be  resupplied.  This  number  will  be  a 
rounded  number,  (see  description  M,  QUAN). 
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SOURCE  LISTINGS  FOR  PERIOD  PROCESSOR  COMBAT  SERVICE  SUPPORT  MODEL 


(AVAILABLE  UNDER  SEPARATE  COVER) 
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CHAPTER  17 


MAJOR  SPECIAL  PURPOSE  PROGRAMS 


1.  INTRODUCTION.  This  chapter  describes  the  major  special  purpose  routines 
used  by  the  Period  Processor.  These  routines  perform  the  initialization, 
termination,  and  restart  functions  required  by  the  processor,  and  are  contained 
in  overlays  1  and  15.  A  macroflow  diagram  is  presented  in  Figure  IV-17-1. 

2.  INITIALIZATION.  The  initialization  overlay  is  called  once — and  only  once — 
at  the  beginning  of  each  Period  Processor  run.  This  occurs  at  the  beginning 

of  each  game  period  and  may  also  occur  if  a  period  is  restarted  due  to  fail¬ 
ure  to  complete  the  period  in  a  single  run  because  of  time  contraints  or  sys¬ 
tem  malfunction.  The  primary  purpose  of  the  overlay  is  to  initialize  all 
necessary  values  in  common  ONE  on  the  appropriate  data  files.  The  Period 
Processor  control  card  is  also  read  in  this  overlay.  Routine  INITIAL  is  the 
driver  for  all  initialization  processing. 

3.  TERMINATION.  The  termination  overlay  is  executed  at  the  completion  of 
all  Period  Processor  runs.  This  occurs  when  the  period  is  completed,  the 
run  executes  the  specified  running  time,  or  the  operator  sets  the  termination 
sense  switch.  The  purpose  of  this  overlay  is  to  store  the  contents  of  common 
onto  data  file  36,  create  a  dump  tape,  and  end  file  the  history  tape.  At  the 
end  of  each  period,  the  event  schedule  is  adjusted  and  all  ongoing  unit  events 
are  terminated.  The  driver  for  the  termination  processing  is  routine  EXIT1. 

4.  RESTART.  Periodic  restart  dumps  are  made  during  the  Period  Processor  runs. 
The  processing  of  a  restart  dump  is  identical  to  that  of  the  termination  with 
the  exception  that  the  history  tapes  are  not  endfiled. 

5.  COMMON  TABLES.  Upon  completing  the  initialization  and  upon  beginning 
the  termination,  the  contents  of  common  and  the  intelligence  tables  on  data 
file  16  are  printed  in  formatted  tables  by  routine  COMMDP.  These  tables  permit 
rapid  access  to  the  status  of  key  variables  at  the  beginning  and  end  of  each 
run. 

6.  FOOD  CONSUMPTION.  Food  consumption  is  calculated  for  all  resolution  units 
three  times  each  day:  0800,  1200,  and  1700  hours.  Routine  EAT  is  called  at 
those  times  to  update  the  quantities  of  food  on  hand  contained  on  the  unit 
status  records.  The  amount  of  food  subtracted  each  time  is  calculated  in  the 
following  manner: 


Consumption 


Strength  •  Rate  •  0.333 


(IV-17-1) 


Figure  IV-17-1. 


Special  Purpose  Routine  Macroflow 
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APPENDIX  A 


INPUT  REQUIREMENTS  FOR  THE  MAJOR  SPECIAL  PURPOSE  PROGRAMS 


The  input  to  the  major  special  purpose  routine,  INITAL,  is  the  single  Period 
Processor  control  card.  That  card  is  described  in  Appendix  A  to  Chapter  2  of 
this  section.  Input  Requirements  for  Executive  Control. 
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APPENDIX  B 

xMAJOR  SPECIAL  PURPOSE  PROGRAM  DESCRIPTIONS 


1.  INTRODUCTION.  Each  routine  described  in  this  appendix  has  a  special¬ 
ized  purpose  as  follows: 

a.  Initialization  -  INITIAL  and  COMMDP. 

b.  Termination  -  XXIT,  EXIT1,  UTILDP,  and  SET41. 

c.  Food  Consumption  -  EAT. 

The  logic  is  more  complex  and  these  routines  are  not  called 
•  with  as  relative  frequency  as  the  utility  routines. 

2.  ROUTINE  INITIAL: 

a.  Purpose.  This  routine  initializes  areas  of  common  at  the  start 
of  each  period  and  certain  dynamic  data  files  at  the  start  of  each  game. 


Input  Variables 

• 

Name 

Source 

Contents 

IRST 

card 

Characters  REST  for  restart,  blanks 
for  start  of  period/game. 

ECSFLG 

card 

1  -  Extended  Core  Storage  will  be  used 
for  resolution  units  instead  of 
data  file  1. 

0  -  Use  data  file  1  instead  of  ECS. 

IRONT 

card 

The  wall-clock  time,  in  minutes,  that 
the  job  is  to  be  allowed  on  the  computer. 

IRTME 

card 

The  wall-clock  time,  in  minutes,  at 
which  a  restart  tape  will  be  dumped. 

ISWCH(4) 

card 

Print  control  switches,  1-on,  0«off. 

ITITLE 

card 

A  desired  title  of  up  to  40  characters 
may  be  input  to  label  the  output  of  the 
run. 

MSTOP 

card 

Game  time  in  centiminutes  that  you  desire 

this  run  to  be  terminated.  If  blank,  run 
will  continue  to  end  of  period. 
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Figure  IV-17-B-1. 
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Figure  IV-17-B-1.  Routine  INITIAL  (continued) 
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Figure  IV-17-B-1.  Routine  INITIAL  (continued) 
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Figure  IV-17-B-1.  Routine  INITIAL  (concluded) 
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Source  Contents 


DF36  Restart  flag*=REST  if  data  tape  is  in  a 

restart  format. 

c.  Output  Variables.  Labeled  common  blocks:  ONE,  EQUIPT,  INCDAT, 

USTDTA,  ENGTRI ,  ZONDAT,  TCFDTA,  TWO,  and  ECS. 

d.  Logical  Flow.  * 

(1)  Block  1.  System  routines  DATA  and  TIME  are  called  to  get  the 
current  date  and  time. 

(2)  Block  2.  The  current  data  and  time  of  the  run  are  outputed. 

(3)  Block  3.  Initialize  labeled  common  areas  to  zero. 

(4)  Block  4.  Get  the  file  name  table  from  the  data  base  and  store 
in  common  ONE. 

(5)  Block  5.  Routine  DSLINT  is  called  to  initialize  some  variables 
in  common  ONE,  that  were  established  in  DSL  execution. 

(6)  Block  6.  Print  pertinent  information  at  the  start  of  the  run. 

(7)  Block  7.  An  input  card  is  read  which  contains  variables  con¬ 
trolling  the  execution  of  the  run.  The  variables  and  their  meaning  are 
discussed  under  Input  Variables  above. 

(8)  Block  8.  Print  data  card  input. 

(9)  Block  9.  Get  the  restart  flag  from  file  36  indicating  the 

status  of  the  data  base.  If  the  flag  is  blank,  a  start  of  period  or  game 
execution  run  must  follow.  If  the  flag  contains  the  characters  REST,  a 
period  restart  execution  run  must  follow. 

(10)  Block  10,  11.  If  the  data  input  control  card  is  missing 
input  values  will  default  as  follows: 

IRST  -  will  be  set  equal  to  the  restart  flag  on  file  36. 

ECSFLG  -  0 

IRUNT  -  600  1 

IRTME  -  60 

ISWCH  -  all  print  switches  will  be  turned  on. 


Name 

IRSTI 
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ITITLE  -  blank 
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MSTOP  -  length  of  period  +  1  minute. 

(11)  Block  12,  13,  14,  15,  16.  The  initialization  flag  controls 

the  flow  of  execution  throughout  routine  INITIAL.  The  flag  is  established 
by  comparison  of  the  two  restart  flags,  one  as  input,  the  other  is  set  on 
file  36  by  the  last  pass  through  routine  EXIT1  from  the  last  execution  run. 

*  If  the  restart  flags  don't  match  the  run  is  aborted,  because  of  either  a 

bad  input  value  or  the  wrong  tape  has  been  used  to  load  the  data  base.  If 
the  restart  flags  match  blanks,  routine  DSLINT  controls  the  initialization 
flag.  Initialization  flag  values  are: 

1  -  Normal  start  of  period 

2  -  Period  restart 

3  -  First  period  of  the  game 

(12)  Block  L100,  17.  If  the  ECS  control  flag  ECSFLG  is  set  to  1 
the  system  routine  OPENMS  is  called  to  open  and  establish  a  file  on 
Extended  Core  Storage. 

(13)  Block  18.  The  character  codes  representing  various  equipment 
item  codes  are  retrieved  from  file  36  and  loaded  into  common  EQUIPT. 

(14)  Block  19.  Establish  common  USTDTA  which  contains  the  Blue 
and  Red  unit  size  estimate  table.  This  information  is  loaded  onto  data 
file  36  by  routine  INCSLD  in  DIVPREP. 

(15)  Block  20.  Establish  the  constant  data  in  common  TCFDTA. 

This  consists  of  fire  unit  status  and  weapon  parameter  data  for  both  Blue 
and  Red.  This  data  is  originally  loaded  on  to  data  file  25  by  the  DIVPREP 
routines  TACLD  and  AFMLD. 

(16)  Block  21.  If  the  first  period  initialization  flag  is  set 
branch  to  L150,  otherwise  continue. 

(17)  Block  22.  Establish  common  INCDAT  by  transfering  INC's 
dynamic  data  from  file  36.  This  data  consists  of  range  limits  for  artillery 
and  attack  helicopter,  request  delay  times  for  helicopters  and  CAS,  active 
target  arrays,  and  redundant  sensing  report  numbers  for  both  Blue  and  Red. 

•  (18)  Block  23.  Establish  common  ZONDAT  by  getting  the  previous 
feba  characteristics  and  division  list  from  file  36. 

(19)  Block  24.  Establish  common  TWO  from  data  file  36.  This 
data  consists  of  Blue  and  Red  unit  information  and  the  previous  event 
table.  Unit  information  includes  unit  Identification  table,  unit  type 
designation  table  and  unit  location  table. 
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(20)  Block  25.  If  the  ECS  flag,  ECSFLG,  is  equal  to  zero  branch 
to  L400,  otherwise  continue. 

(21)  Block  L350.  The  unit  status  file  of  each  Blue  and  Red 
resolution  unit  will  be  created  and  dynamically  maintained  throughout  the 
run  in  Extended  Core  Storage  to  eliminate  disk  accessing. 

(22)  Block  L400.  If  the  initialization  flag  does  not  indicate 
a  period  restart  branch  to  block  28,  otherwise  continue. 

(23)  Block  26.  Transfer  the  following  dynamic  data  from  file  36 
to  their  respective  labeled  common  areas:  sensor  locations  to  TOO, 
quadriture  codes  to  ENGTRI,  weather  zones  to  ONE. 

(24)  Block  27.  Set  initialization  flag  to  restart  for  the  re¬ 
mainder  of  the  routine.  Then  branch  to  L7000. 

(25)  Block  28.  Set  the  IUID  of  the  last  Blue  unit  and  the  IUID 
of  the  first  Red  unit  into  BPOINT  and  RPOINT,  and  store  in  common  ONE. 

Also  from  file  36  transfer  three  ENGINEER  submodel  control  variables  to 
common  ENGTRI . 

(26)  Block  L150.  Set  the  weather  zone  data  into  common  ONE. 

This  data  was  loaded  in  DIVPREP  routine  WETHLD  and  stored  on  data  file  4. 

(27)  Block  29.  Set  food  consumption  rates  from  file  11,  mobility 
category  codes  and  rate  default  table  from  file  14,  and  the  move  priority 
table  from  file  9  into  labeled  common  ONE.  Also  set  the  break-point 
temperature  to  90  degrees. 

(28)  Block  L1300.  Establish  sensor  location  data  in  common  TOO 
from  file  20. 

(29)  Block  30.  Set  the  initial  seed  from  the  random  number 
generator  routine  RANDU  to  1000  and  store  it  in  labeled  common  area  ONE. 

(30)  Block  31.  If  the  initialization  indicator  is  set  for  start 
of  period  initialization  branch  to  L6001,  otherwise  continue. 

(31)  Block  L5000.  Create  data  file  16  as  a  period  processor 
scratch  file. 

(32)  Block  5005.  Using  data  file  5  as  a  scratch  area  transfer 
data  file  31  to  the  end  of  the  disk.  This  file  has  records  periodically 
added  to  it,  causing  all  data  loaded  above  it  to  be  shifted.  This  is  a 
very  time  consuming  exercise  that  will  be  eliminated  by  the  transfer. 

(33)  Block  L5026.  Initialize  all  event  table  entries  to  7000000. 
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(34)  Block  L5035.  Create  data  file  12  as  a  communication  link 
between  period  processor  submodels. 

(35)  Block  32.  Initialize  sensor  report  number  array  to  zero 
and  store  in  common  INCDAT. 

(36)  Block  33.  Call  routine  EVTSET  to  set  the  first  CSS  event 
to  occur  1  hour  into  the  period. 

(37)  Block  L6000.  In  the  DIVPREP  routine  TOELD  unit  status  file 
skeletons  were  created  containing  unit  identification,  location,  and  their 
respective  on-hand  equipment.  The  identification  and  location  data  for 
each  created  unit  is  now  transfered  from  the  unit  status  file  to  tables  in 
common  TWO,  namely,  a  UID,  UTD,  and  unit  location  table.  Since  the  TOELD 
several  other  DIVPREP  load  programs  have  added  pertinent  unit  information 
to  the  data  base.  At  initialization  time  this  information  is  extracted 
from  the  data  base  by  UTD  type  and  loaded  into  the  appropriate  unit  status 
file. 


(38)  Block  L6001.  The  start  of  period  logic  rejoins  the  start  of 
game  logic. 

(39)  Block  34.  File  48  is  created  at  the  beginning  of  each 
period.  This  file  is  dynamically  filled  with  pertinent  loss  data  each 
time  a  unit  assessment  is  made  due  to  fire-power  losses.  The  file  is 
then  used  for  post  period  reports. 

(40)  Block  L6500.  Routine  UPMASK  is  called  for  all  resolution 
units  at  the  first  period  of  a  game  initialization.  This  routine  creates 
the  dominate  mask  array  on  the  unit  status  file,  and  also  sets  the  unit 
location  at  which  the  mask  was  made.  The  mask  array  is  used  to  determine 
line-of-sight  by  various  fire-power  submodels. 

(41)  Block  35.  For  new  period  initialization  set  the  starting 
period  time  to  zero. 

(42)  Block  36.  If  either  the  barrier  or  mine  field  data  files 
have  not  been  loaded  branch  to  L7000,  otherwise  continue. 

(43)  Block  37.  Call  routine  INITMN  to  schedule  an  ENGINEER 
submodel  event  to  continue  efforts  on  a  mine  field  that  was  started 
but  not  completed  in  the  preceding  period. 

(44)  Block  L7000.  Restart  initialization  logic  rejoins  here. 

(45)  Block  38.  Routine  IOTERN  is  called  to  establish  the  terrain 
cell  size  and  the  number  of  cells  in  the  X  and  Y  direction  and  to  store 
this  data  in  common  ONE. 
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(46)  Block  39.  Is  console  switch  6  on?  not  branch  to  block  41, 
otherwise  continue. 

(47)  Block  40.  Switch  6  being  on  indicates  a  desire  to  terminate 
a  period  which  up  to  this  point  had  not  been  normally  terminated.  In 
short,  the  status  of  some  data  files  are  in  a  restart  format  and  must  be 
converted  to  end-of-period  format.  This  is  accomplished  by  calling  routine 
XXIT  with  the  first  calling  argument  equal  to  the  characters  FINI . 

(48)  Block  41.  Routine  COMMDP  dumps  pertinent  start  of  run 
information  for  the  ease  of  run  verification  or  debug  purposes. 

(49)  Block  42.  End  of  routine  INITIAL. 
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3.  ROUTINE  LOCTAP: 


Not  used. 


« 


.  '• 


4.  ROUTINE  COMMDP : 

a.  Purpose.  This  routine  dumps  common  ONE  and  TWO  and  data  file  16 
at  the  beginning  and  end  of  each  period  to  allow  the  data  to  be  checked. 

b.  Input  Variables.  Common  ONE  and  TWO  and  data  file  16  data. 

c.  Output  Variables.  Listings  of  variables. 

d.  Logical  Flow  (Figure  IV-17-B-2). 

(1)  Block  1.  The  contents  of  common  ONE  are  printed  with  appropriate 
headings . 

(2)  Block  2.  The  event  codes  and  event  times  are  unpacked  from  the 
event  table  and  printed. 

«r 

n 

(3)  Block  3.  The  UID,  UTD,  and  location  tables  are  printed 
sequentially. 

(4)  Block  4.  The  barrier  data,  equipment  code  arrays,  and  sensor 
location  tables  are  printed  with  identifying  headings. 

i 

(5)  Block  5.  The  DSL  labels  associated  with  the  units  from  data 
»  file  55  and  the  Intelligence  and  Control  data  stored  in  data  file  16  are 

obtained  and  printed  with  appropriate  headers. 

(6)  Block  6.  The  secondary  equipment  tables  are  retrieved  and 
printed  with  descriptive  titles.  Return  control  to  the  calling  routine. 

5.  ROUTINE  XXIT: 

a.  Purpose.  This  routine  allows  information  to  be  printed  and  dumped 
before  a  routine  EXIT1  is  called  to  terminate  the  job  or  to  make  a  restart 
tape. 


C 
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Figure  IV-17-B-2.  Routine  CC.  np 
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b. 

Input  Variables: 

Name 

Source 

Contents 

IALFA 

Call 

A  four-character  alphanumeric  code  describing 
the  reason  XXIT  was  called. 

IER 

Call 

A  numeric  error  code. 

c.  Output  Variables.  None. 

d.  Processing  Description.  If  IALFA  is  set  at  4HFINI  (period  completed), 
4H0PER,  or  4HTIME,  call  EXIT1  and  stop  processing.  If  IALFA  is  set  at 
4HRSTM,  call  EXIT1  and  return  control  to  the  calling  routine.  If  IALFA  is 
set  to  any  other  value,  call  the  system  routine  to  dump  common  ONE  and  TWO, 
call  EXIT1 ,  and  stop  processing. 

6.  ROUTINE  EXIT1: 


a.  Purpose.  This  routine  adjusts  parameters  as  required  at  the  end  of  a 
period  and  writes  the  end-of-period  dump  tapes.  It  also  writes  the  restart 
dump  tapes. 


b. 


Name 

IALFA 


Input  Variables: 

(1)  Common  ONE  and  TWO. 

(2)  Other  Variable: 

Source  Contents 

TWO  A  four-character  alphanumeric  code  describing 

the  reason  EXIT1  was  called. 


c.  Output  Variables: 

(1)  Common  ONE  and  TWO. 

(2)  Other  Variables: 


Name 

Destination 

Contents 

ONE 

DF36 

Data  to  be  stored 

TWO 

DF36 

Data  to  be  stored 

d.  Logical  Flow  (Figure  IV-17-B-3) : 

(1)  Block  1.  The  four-character  alphanumeric  code  IALFA  indicates 
the  reason  EXIT1  was  called.  IALFA  of  OPER  denotes  an  operator  termination, 
TIME  indicates  the  computer  run  time  was  exceeded,  RSTM  means  a  request  to 
create  a  restart  tape  is  being  made,  and  FINI  denotes  the  period  is  completed. 
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Any  other  code  is  assumed  to  indicate  a  fatal  error.  An  appropriate  message 
is  printed  for  each  error. 

(2)  Block  2.  If  a  restart  tape  is  requested,  transfer  control  to 
block  LI,  otherwise  control  goes  to  block  L20. 

(3)  Block  LI,  Data  stored  in  common  ONE  and  TWO  are  moved  to  data 
file  36  in  restart  format.  The  word  IRST,  indicating  a  restart  tape  is  to  be 
created,  is  set  to  REST.  Control  transfers  to  block  L5000  to  write  the  tape. 

(4)  Block  L20.  Process  the  necessary  adjustments  for  termination  of 
a  period.  The  times  stored  in  data  file  20  associated  with  intelligence 
sensors  are  adjusted  by  subtracting  TCLOCK.  The  unit  status  record  of  each 
unit  is  updated  by  subtracting  TCLOCK  from  LTASMT  and  ENGTM  and  by  setting 
NTIME  and  BATID,  to  zero.  All  events  in  the  table  of  automatic  events  are 
adjusted  by  subtracting  TCLOCK,  and  all  DSL-ordered  events  are  terminated. 

The  common  ONE  and  TWO  tables  are  stored  on  data  file  36. 

(5)  Block  L5000.  This  block  closes  the  dump  tapes.  If  a  restart 
tape  is  being  requested,  end  of  files  are  written  on  logical  units  39  and  40, 
UTILDP  is  called  to  dump  the  data  lies  to  logical  unit  41,  and  control  goes 

to  block  5.  If  this  is  not  a  restart  tape  request,  two  consecutive  end  of  files 
are  written  on  units  39  and  40  as  an  end-of-data  indicator.  One  end  of  file 
is  written  on  logical  unit  41  and  the  data  files  are  dumped  to  it.  Logical 
unit  41  is  rewound  and  a  request  that  this  magnetic  tape  be  removed  and  another 
mounted  is  made.  When  the  mounting  is  complete,  a  second  dump  of  the  data 
files  is  made.  The  routine  COMMDP  is  called  to  print  areas  of  common  ONE  and 
TWO. 

(6)  Block  5.  If  a  restart  tape  was  requested,  control  is  returned  to 
the  routine  calling  EXIT1;  otherwise,  a  message  is  printed  and  processing  is 
terminated. 

7.  ROUTINE  SET41: 

a.  Purpose.  This  CP  COMPASS  routine  is  used  to  set  the  operating 
system  file  environment  table  buffer  pointers  for  TAPE41  to  point  to  a 
user-defined  array  to  be  referenced  as  a  circular  input/output  buffer. 

This  permits  the  routine  UTILDP  to  be  compiled  with  a  minimum  length  buffer 
and  a  larger  in  unused  core  to  be  utilized  at  object  time.  This  routine  is 
optional  but  provides  greater  efficiency  on  a  CDC6000  series  computer. 

b.  Input  Variables: 


Name 

Source 

Contents 

LFWA 

Call 

Address  of  array  to  be  used. 

LEN 

Call 

Length  of  array. 

LSET 

Call 

Flag  indicating  the  desired  setting  of  buffer 

pointer: 

LSET-1,  Set  to  array. 

LSET-2,  Reset  to  initial  value. 
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c.  Output  Variables:  None. 

d.  Processing  Description: 

(1)  LSET=1.  SET41  saves  the  initial  file  environment  table  pointers 
internally,  sets  the  pointers  to  the  array  requested,  and  returns  control 

to  the  calling  routine. 

(2)  LSET=2.  SET41  outputs  data  remaining  in  the  output  buffer, 
restores  the  file  environment  table  pointers  to  their  initial  value,  and 
returns  control  to  the  calling  routine. 

8.  ROUTINE  EAT: 

a.  Purpose.  EAT  is  called  by  MINUET  three  times  per  game  day  at  0800, 
1200,  and  1700  hours.  It  computes  the  food  consumption  for  each  resolution 
unit  of  both  the  Red  and  Blue  forces. 


b.  Input  Variables: 


Name 

Source 

Content 

RP0INT 

ONE 

IUID  of  lowest  Red  unit. 

BP0INT 

ONE 

IUID  of  highest  Blue  unit. 

PRESTR 

ONE 

Present  strength  of  a  unit. 

IBFOOD 

ONE 

Amount  of  food  consumed  by 
Blue  force. 

each 

man  per  day, 

IRFOOD 

ONE 

Amount  of  food  consumed  by 
Red  force. 

each 

man  per  day, 

UNTL0C 

TWO 

Unit  coordinate  location. 

c. 

Output  Variables: 

Name 

Destination 

Content 

IAMT 

TWO 

Amount  of  food  consumed  by 
eating  period. 

a  unit  each 

E0H(1) 

DF1 

Amount  of  food  on  hand  for 

each 

unit. 

d.  Logic  Flow  (Figure  IV-17-B-4) : 

(1)  Block  1.  Set  IPASS  equal  to  zero.  Set  K  equal  to  BP0INT  to 
initialize  the  Blue  force. 

(2)  Block  2.  Compute  the  amount  of  food  consumed  by  each  man  of  the 
Blue  force  during  this  eating  period. 
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If  the  sum  is 


(3)  Block  3.  Sum  the  X  and  Y  coordinates  of  the  unit, 
zero,  the  unit  is  nonresolution  and  will  not  be  considered. 

(4)  Block  4.  Call  GETRCD  to  retrieve  the  unit's  status  record  from 
data  file  1. 

(5)  Blocks  5  and  6.  Compute  the  amount  of  food  consumed  by  this  unit 
during  this  eating  period.  Subtract  this  amount  of  food  from  the  unit's  status 
record. 

(6)  Block  7.  Call  PUTRCD  to  replace  the  unit's  status  record 
on  data  file  1. 

(7)  Block  L100.  If  all  units  of  the  designated  force  have  not 
been  processed,  control  goes  to  block  3  to  get  the  next  unit. 

(8)  Block  8.  Check  IPASS.  If  IP ASS  equals  one,  the  Red  force 
has  been  processed.  Control  returns  to  Che  calling  routine.  If  IPASS 
equals  zero,  processing  continues. 

(9)  Block  9.  Set  IPASS  equal  to  one.  Set  K  equal  to  RPOINT  to 
initialize  Red  force.  Compute  the  amount  of  food  to  be  consumed  by  each  man 
of  the  Red  force  during  this  eating  period,  and  transfer  control  to  block  3. 
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APPENDIX  C 


OUTPUT  DESCRIPTIONS  OF  MAJOR  SPECIAL  PURPOSE  ROUTINES 


1.  INTRODUCTION.  This  appendix  contains  samples  and  detailed  descriptions  of 
printed  output  from  major  special  purpose  routines  of  the  Period  Processor.  A 
figure  depicts  the  format  of  each  routine  printout.  In  the  figure  an  alpha¬ 
betical  character  (descriptor)  designates  an  appropriate  line  or  group  of  lines 
that  is  explained  in  the  paragraphs  below. 

2.  ROUTINE  INITAL.  The  output  of  INITAL,  which  initializes  areas  of  common 
at  the  start  of  each  period,  is  shown  in  Figure  IV-17-C-1,  and  described  as 
follows. 


Output 

Descriptor 


Explanation 


A 


The  date  that  this  Period  Processor  run  started  execution  is 
printed. 


B  The  wall-clock  time  this  Period  Processor  run  started  execution 

is  printed. 


C  After  the  call  to  DSLINT  is  completed,  the  values  returned  in 

the  variables  DAY,  HOUR,  MINUTE,  LGTPER  (length  of  period) 
and  INTFLG  (initialization  flag)  are  printed.  This  infor¬ 
mation  is  used  to  verify  that  the  correct  period  is  on  the 
DIVWAG  data  file. 


D  The  data  that  is  input  on  the  Period  Processor  data  card  is 

printed.  This  line  of  print  contains  the  following: 

.  whether  the  DIVWAG  data  file  to  be  executed  is  expected 
to  be  a  restart  file 

.  the  wall-clock  time  allowed  for  this  computer  run 

.  the  interval  in  wall-clock  minutes  between  creation  of 
a  restart  dump 

.  the  control  for  the  print  switches  (1  means  switch  is  on, 
otherwise  it  is  off) 

.  a  string  of  40  characters  to  be  printed  as  a  heading 

.  the  game  time  in  centiminutes  where  the  user  desires 
this  run  to  stop. 

An  additional  print  statement  that  does  not  appear  in  the  figure 
is 


C 


RESTART  CONTROL  FROM  FILE  36.  IRST-REST 
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t 


The  value  of  the  restart  control  is  obtained  from  the  DIVWAG 
data  file.  This  value  can  be  either  REST  which  indicates  it 
is  a  restart  dump  or  zero  which  prints  as  blanks  and  indicates 
it  is  not  a  restart  dumped  file. 

3.  ROUTINE  EXIT1.  This  routine  adjusts  parameters  and  writes  end-o£-period 
and  restart  dump  tapes.  The  output  is  listed  as  follows: 

DIVWAG  ENTERED  EXIT1.  TIME  -  HH.MM.SS. 

•  This  print  occurs  each  time  this  routine  is  entered.  It  contains  the  time 

in  hours,  minutes,  and  seconds. 

THE  PERIOD  HAS  ENDED.  NEW  DSL  MUST  BE  WRITTEN  IN  ORDER  TO  CONTINUE  WITH  DIVRUN. 

When  this  print  occurs  the  DSL  file  has  been  set  equal  to  zero,  a  double 
end-of-file  is  put  on  the  period  history  tape,  a  call  is  made  to  COMMDP, 
the  times  in  the  tables  in  common  are  reduced,  ongoing  ordered  events 
are  stopped,  common  ONE  and  TWO  are  put  into  data  file  36,  data  file  21 
is  cleared,  all  tapes  are  rewound,  and  a  call  is  made  to  UTILDP. 

THE  TAPES  FOR  THIS  RUN  HAVE  AN  END  TIME  OF  DAY  IIII  HOUR  IIII  MINUTE  IIII 

I  This  print  contains  the  end  of  period  time  for  this  run. 

A  RESTART  TAPE  HAS  BEEN  CREATED  AT  DAY  »  IIII  HOUR  »  IIII  MINUTE  -  IIII 

This  print  occurs  when  a  restart  tape  is  to  be  created,  indicated  by  RSTM 
t  in  IDUM(2) .  An  end-of-file  is  written  on  the  period  history  tape,  common 

[  ONE  and  TWO  are  put  into  data  file  36,  and  a  call  is  made  to  UTILDP. 

DIVRUN  HALTED  DUE  TO  COMPUTER  RUNNING  TIME.  PERIOD  MAY  BE  CONTINUED  BY  A 
DIVRUN  RESTART. 

f  This  print  occurs  when  computer  running  time  has  been  exceeded.  Double 

end-of-files  are  put  on  the  period  history  tape,  common  ONE  and  TWO  are 
>  put  into  data  file  36,  the  tapes  are  rewound,  and  calls  are  made  to 

UTILDP  and  COMMDP. 

DIVRUN  TERMINATED  BY  THE  OPERATOR.  PERIOD  MAY  BE  CONTINUED  BY  A  DIVRUN  RESTART. 

f  This  print  occurs  when  the  Period  Processor  run  has  been  terminated  by  the 

operator.  The  value  of  IDUM(4094)  is  set  equal  to  32  and  the  program 

*  continues  the  same  as  for  termination  for  time. 

•  EXIT  FROM  SUBROUTINE  AAAA  BECAUSE  OF  ERROR.  ERROR  NO.  IER  -  IIIIII 

•  This  print  occurs  when  a  call  is  made  to  this  routine  by  any  routine  in 

the  model.  The  calling  routine  is  Indicated  by  AAAA  and  the  value  of 
IER  is  printed.  A  call  is  made  to  COMMDP  to  dump  core  and  execution 
stops. 


C 
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4.  ROUTINE  COMMDP.  At  the  beginning  and  end  of  each  Period  Processor  run, 
the  routine  COMMDP  is  called  to  print  key  information  as  it  exists  at  the 
current  game  time.  A  sample  printed  output  from  routine  COMMDP  appears  in 
Figure  IV-17-C-2  and  is  described  as  follows: 


Output 

Descriptor 


Explanation 


A  The  IFNT  array  is  printed  under  the  heading  of  FILE  NAME  TABLE. 


B  Several  values  of  labeled  common  ONE  are  printed.  These 

variables  and  their  meanings  are  described  under  the  descrip¬ 
tion  of  data  file  36  in  Chapter  2  of  Section  VII,  DIVWAG  Data 
Files. 

C  The  EVENT  TABLE  is  printed  after  unpacking  the  event  code  and 

event  time.  It  is  read  by  counting  across  the  line  of  print 
for  each  10  entries  of  the  event  table. 

D  The  UNIT  INFORMATION  that  is  printed  is  read  across  the  line  of 

print  as  follows:  the  unit  identification  number,  the  unit 
identification  code,  the  unit  type  designator,  and  the  unit 
location  (first  X  coordinate  followed  by  Y  coordinate). 

E  The  BARRIER  DATA  array  is  printed  as  read  from  data  file  16. 

F  The  EQUIPMENT  CODES  are  read  from  data  file  16  and  printed. 

The  Blue  force  is  printed  first  followed  by  the  Red  force. 

G  The  SENSOR  LOCATIONS  for  each  of  the  forces  are  printed  as 

follows:  five  sensors  per  line  of  print  with  the  X  coordinate 
followed  by  the  Y  coordinate  for  each  sensor,  Blue  force  is 
the  first  100  sensors  followed  by  the  Red  force. 

H  This  is  a  dump  of  the  unit  battle  directory  table  which  is 

described  in  detail  in  Appendix  C,  Chapter  2,  Section  III. 

I  The  INCS  DATA  is  the  intelligence  data  that  is  stored  on  data 

file  16  beginning  at  word  7101  through  word  10501.  This  data 
is  described  in  the  section  on  Data  File  16  in  Chapter  2  of 
Section  VII. 


5.  Routine  UTILDP.  Routine  UTILDP  of  the  Period  Processor  is  identical  to 
the  utility  dump  program  described  in  Chapter  4  of  Section  VII  with  the  following 
exceptions : 

a.  The  program  card  is  replaced  by  a  subroutine  card. 

b.  A  return  statement  is  inserted  before  the  end  card. 

c.  The  call  to  OPENMS  is  removed. 
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Routine  COMMDP  Printed  Output  Sample  (Continued 
on  Next  Page) 


IV-17-C-5 


i 


I 


W«¥  TftntE 


UNIT  IHF  T  jr**| 


(5 H 


1 

n  17’uns t 

r«r  i 

j 

0 

.» 

•9  IU'JhmT  T 

<lp  T.l 

) 

0 

n^n-.-OTT 

JM  J 

i 

0 

t, 

■■’.  1 1  ^  n  •  i  T  » 

3 

9 

r- 

p  ‘  1  1  Mnp«r 

T  r  p  a 

3 

0 

ni 1 5rMT  T 

tjw»  1 

) 

0 

7 

1  1  1  MP3P 

I  rr  t 

3 

3 

<* 

c  l  j  c  vftfln 

jarn 

3 

0 

o 

9  11  :n*'i  T 

U*»IJ 

3 

3 

n 

9 

TMCT 

3 

0 

n 

9  taj“<**p 

j"Fn 

I 

0 

i? 

9  121n*"T  t 

U«T> 

3 

0 

1 x 

9  1  ?!  unfit* 

irn 

3 

r; 

t'* 

9  ijov° 

jttPn 

3 

0 

i  5 

9  1  *«;  "*4it  T 

09 1 J 

3 

3 

t6 

n  tOlM?c.a 

iwrr. 

3 

0 

!  7 

*'ic:rpap 

j^n 

1 

0 

19 

9iflprvri 

•ip  i  j 

3 

0 

19 

ni2 j  TNCft 

l»'tr 

3 

0 

23 

911  ‘•"OD^ 

TPPfl 

3 

0 

?t 

9  1  7fl  n*IT  T 

•.INI  J 

3 

0 

?? 

91X9W04  T 

I9PT 

3 

0 

?  1 

n  IPn^MTT 

•jrr.i 

) 

3 

2  fa 

9 1 1 A T 

IflCT 

3 

c 

29 

91X39MTT 

u0 1 J 

3 

a 

76 

9  1C  Atfr«>T 

JPIM 

J 

a 

27 

<>!/l"V"PT 

VnlH 

3 

0 

29 

t»1  90Tl  so 

vplm 

1  1991] 

79?  oo 

?9 

9  l  S*»T?pe 

VrlM 

1  JU913 

95200 

»0 

9121MOftM 

T  sow 

3 

0 

u 

oMirvTt 

•ipT  J 

1 

fi 

X? 

91 ??9V*u 

IflLM 

3 

0 

gtarK^PT 

VP  LH 

3 

0 

•Jfa 

vai* 

1  36233 

77X00 

39 

ni  a  nr^pp 

vai* 

l J79 J3 

?o?oc 

X*. 

9iatr t»p 

VflL9 

11*2:3 

71200 

7  7 

niijwoar 

TPPM 

3 

0 

X9 

9  1 7 19W  T  T 

U*»T  J 

3 

0 

39 

9ii x^vao 

J 

0 

fa(3 

9  larcTx:** 

Efllt 

1 

0 

«*l 

9  1  IPMPCp 

JePL 

3 

0 

fa  2 

9iarc95T 

JrLL 

J 

0 

faX 

9t«CC9M*l 

J*IL 

) 

0 

«.  <• 

nt0307rn 

f  p^p 

ni33 

9*100 

fa* 

OtOlPre-M 

J°5F 

1 

0 

1*9 

9101HPP»I 

Jppp 

1 

0 

fa7 

«13flnMF»i 

Ofl^F 

3 

0 

fa  9 

91372747 

cr«I 

9733  j 

99900 

fa9 

■»t022aat 

tnif 

3 

0 

50 

9t3’?«ai 

I"«I 

3 

0 

M 

810?2C«T 

I"HI 

3 

0 

'? 

9t2?rs*T 

t  F  *i  I 

1 

0 

53 

9  10507SP 

F.S55 

) 

0 

*fa 

nioi«r«M 

r.rr* 

90133 

991  C  0 

55 

910337a" 

rasn 

3 

0 

e6 

fl  lOinnan 

jwnn 

99101 

9fal00 

*•7 

910007TI 

ETTJ 

996  3  J 

99900 

r9 

a  n«Mf*Tt 

urj 

1 

0 

*9 

91C9TSTT 

JrT  J 

1 

0 

►  0 

9 1 30 07 MM 

F*MA 

1 

0 

M 

.91H01.TMM 

j*ni 

3 

3 

Figure  IV-17-C-2.  Routine  COMMDP  Printed  Output  Sample  (Continued) 
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SOURCE  LISTINGS  FOR  PERIOD  PROCESSOR  MAJOR  SPECIAL  PURPOSE  ROUTINES 
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CHAPTER  18 


DIVWAG  SCENARIO  LANGUAGE  INTERFACE  ROUTINES 


1.  GENERAL  DESCRIPTION.  The  routines  discussed  in  this  chapter  are  used  by 
the  Period  Processor  to  access  the  tables  written  by  the  DIVWAG  scenario 
language  compiler.  The  Period  Processor  must  access  these  tables  to  acquire 
the  next  order  that  a  unit  is  to  execute,  to  obtain  a  list  of  the  units 
participating  in  a  particular  battle,  or  to  determine  if  a  condition  of  battle 
termination  has  been  met.  The  purpose  of  each  routine  is  discussed  in  the  sub¬ 
sequent  paragraphs. 

2.  ROUTINE  DOSR.  The  primary  purpose  of  this  routine  is  to  provide  the  event 
scheduling  routine  with  the  next  order  a  particular  unit  is  to  execute.  Th,f 
is  accomplished  by  finding  the  unit  identification  (UID)  input  to  DOSR  in  th«. 
unit  battle  directory  table  (UBT),1  retrieving  its  unit  scenario  from  the  data 
file,  determining  the  next  order  the  unit  is  to  execute,  and  returning  that 
order,  in  the  form  of  an  array,  to  the  routine  calling  DOSR.  The  orders  are 
executed  in  the  order  in  which  they  occur  in  the  scenario  unless  the  scenario 
contains  a  conditional  or  the  pseudo  order  GOTO.  If  a  GOTO  is  encountered,  the 
order  indicated  will  be  returned.  If  a  conditional  is  encountered,  it  will  be 
passed  to  routine  TRUTH  for  processing, and  the  order  dictated  by  the  value 

of  the  conditional  as  determined  by  TRUTH  (TRUE  or  FALSE) — will  be  returned. 
DOSR  will  also  return  orders  to  be  executed  by  a  force  (e.g.,  engineering 
task)  upon  request.  This  routine  is  also  responsible  for  the  storage  of  the 
unit  scenario  pointer  to  the  order  the  unit  is  currently  executing;  the 
pointer  is  stored  in  the  unit  battle  table. 

3.  ROUTINE  DBSR.  This  routine  has  the  task  of  determining  if  a  particular 
battle  should  be  concluded  and  setting  up  the  orders  to  be  executed  by  the 
participating  units  upon  conclusion  of  the  battle.  The  first  part  of  the 
task  is  accomplished  by  locating  the  battle  identification  input  to  DBSR 

in  the  unit  battle  table,  retrieving  it's  battle  paragraph  from  the  data  file 
and  requesting  that  each  conditional  in  the  battle  paragraph  be  processed  by 
TRUTH  until  all  of  the  conditionals  have  been  processed  or  one  is  found  to 
be  true.  The  pointers  to  the  orders  that  the  units  are  to  execute  upon 
conclusion  of  the  battle  are  available  from  the  battle  paragraph.  DBSR  sub¬ 
stitutes  these  pointers  for  the  order  pointers  for  each  unit  currently  stored 
in  the  unit  battle  table. 

4.  ROUTINE  TRUTH.  The  function  of  this  routine  is  to  determine  if  the 
conditional  is  true  or  false.  No  distinction  is  made  between  unit  scenario 
and  battle  paragraph  conditionals.  The  process  required  to  determine  the  truth 
of  a  conditional  is  dependent  upon  the  nature  of  the  conditional.  It  can  be 

as  simple  as  comparing  the  time  in  the  conditional  to  the  current  game  time, 
or  as  complex  as  retrieving  a  unit  status  file,  finding  the  percentage  of  an 


1.  See  Section  III,  Chapter  2,  DSL  Compiler,  for  a  description  of  the 
tables  mentioned  in  this  chapter. 
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equipment  item  on  hand,  comparing  it  to  the  value  in  the  conditional,  and 
negating  the  result. 

5.  ROUTINE  BSUIDL.  This  routine's  only  task  is  to  provide  a  list  of  the 
unit  identifications  of  the  units  participating  in  a  particular  battle. 
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APPENDIX  A 


INPUT  REQUIREMENTS  FOR  DIVWAG  SCENARIO  LANGUAGE  INTERFACE  ROUTINES 


The  Input  to  the  DIVWAG  scenario  language  (DSL)  interface  routines 
consists  of  the  tables  generated  by  the  DSL  compiler  (described  in  Section 
III,  Chapter  2,  DSL  Compiler)  and  various  constant  data  files  (e.g.,  unit 
status  file,  terrain  data  file,  weather  data  file). 
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APPENDIX  B 


DIVWAG  SCENARIO  LANGUAGE  INTERFACE  PROGRAM  DESCRIPTIONS 

1.  INTRODUCTION.  The  routines  described  in  this  appendix  access  and  extract 


data  from  the  DIVWAG  Scenario 
Compiler ,  when  required  by  the 

Language  (DSL)  order  file,  written  by  the  DSL 
Period  Processor. 

2 .  ROUTINE 

DSLINT : 

* 

a.  Purpose.  This  routine 
some  variables  in  Common  ONE. 

initializes  the  variables  in  Common  DSL  and 

b.  Input  Variables: 

Name 

Source 

Contents 

IDUM 

ORDFIL 

Common  variables  set  by  this  routine. 

c.  Output  Variables: 

(1) 

and  INTFLG. 

Standard  Common  Block  Variables.  DAY,  HOUR,  MINUTE,  LGTPER, 

(2) 

Other  Variables: 

* 

Name 

Destination 

Contents 

ORDFIL 

DSL 

DSL  data  file  number. 

BATPT 

DSL 

Pointer  to  first  battle  in  unit  and  battle 
directory  table. 

r 

UNTPT 

DSL 

Pointer  to  last  unit  in  unit  and  battle 
directory  table. 

OUT 

DSL 

Logical  file  name  of  printer. 

d.  Processing  Description.  This  routine  initiates  the  values  of  ORDFIL 
and  OUT  with  constants.  It  then  reads  and  stores  the  appropriate  values  of 
DAY,  HOUR,  MINUTE,  LGTPER,  INTFLG ,  BATPT ,  and  UNTPT  from  the  data  file 
designated  by  ORDFIL. 

» 

3.  ROUTINE  DOSR: 

a.  Purpose.  This  routine  extracts  the  next  order  that  the  unit  (UID)  is 
*  to  process  from  its  unit  scenario  and  returns  it  in  the  DST  array. 

b.  Input  Variables: 

(1)  Standard  Common  Block  Variable.  TCLOCK. 

C 
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(2) 

Other  Variables: 

Name 

Source 

Contents 

UID 

Call 

Identification  of  unit  for  which  the  order  is 
to  be  returned. 

DST(l) 

Call 

P  count  indicator: 

•  If  PKNT  is  less  than  zero,  P  counter  is  to  be 
incremented  (See  FRCORD  exceptions  below) . 

•  If  PKNT  is  greater  than  zero,  P  counter  is 
not  to  be  incremented. 

•  If  PKNT  is  equal  to  zero,  P  counter  is  not 
to  be  incremented;  but,  if  P  counter  points 
to  an  order  involving  a  series  of  coordi¬ 
nates  (e.g.,  move,  fly),  P  counter  will 

be  set  to  point  to  the  order  containing 
the  first  coordinate  of  the  series  and 
that  order  will  be  returned. 

•  If  PKNT  is  equal  to  998,  a  first  call  by 
FRCORD  is  indicated. 

•  If  PKNT  is  equal  to  999,  a  subsequent  call 
by  FRCORD  is  indicated. 


ORDFIL 

DSL 

DSL  data  file  number. 

UNTPT 

DSL 

Pointer  to  last  unit  in  unit  and  battle 
directory  table. 

OUT 

DSL 

Logical  file  name  of  printer. 

UBT 

DF  ORDFIL 

Unit  and  battle  directory  table. 

OARY 

DF  ORDFIL 

Unit  scenario. 

c. 

Output  Variables: 

Name 

Destination 

Contents 

UBT 

DF  ORDFIL 

Updated  P  counter. 

DST 

Call 

Next  order  that  unit  is  to  execute. 

d. 

Logical  Flow  (Figure  IV- 

•18-B-l) : 

(1)  Block  1.  If  DST (1) 

(IDST) ,  is  equal  to  999  a  subsequent  FRCORD 

call  is 

indicated  and  control  is 

transferred  to  block  L2010. 

(2)  Block  L1000.  Unit  and  battle  directory  table  is  brought  into 
core  and  scanned  for  a  UID  match.  If  one  is  not  found,  an  error  message  is 
printed;  otherwise,  the  unit  scenario  of  that  unit  is  brought  into  core. 

(3)  Block  2.  IDST  is  checked  to  determine  what  is  expected  of  DOSR 
with  control  being  transferred  to  blocks  L2010,  L2402,  or  L2500  for  negative, 
zero,  or  positive  values  respectively. 
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(4)  Blocks  L2400  and  3.  The  initial  call  to  DOSR  for  each  unit's 
orders  is  made  with  DST(l)  set  equal  to  zero.  If  the  P  counter  (PKNT)  of 
the  unit  is  zero,  it  is  reset  to  one  and  control  is  transferred  to  block 
L2010.  If  PKNT  points  to  an  order  containing  coordinates  (e.g.,  fly,  move), 
it  will  be  decremented  until  it  points  to  the  unit  and  battle  directory 
table  order  in  that  series  and  that  order  will  be  returned;  otherwise,  the 
order  that  PKNT  points  to  will  be  returned. 

(5)  Block  L2010.  OARY (21 ,PKNT)  is  checked  to  determine  if  PKNT  is 
to  be  incremented  by  one  or  set  equal  to  OARY (21 ,PKNT) .  If  PKNT  points  to 
a  conditional,  TRUTH  is  called  to  process  the  conditional,  PKNT  is  set  to 
the  value  indicated,  and  the  process  is  repeated.  If  PKNT  is  greater  than 
the  number  of  orders  in  this  unit  scenario,  control  is  transferred  to  block 
L4000;  otherwise,  control  transfers  to  block  L2500. 

(6)  Block  L4000.  When  a  unit  has  finished  processing  all  of  its 
DSL  orders,  it  is  assigned  to  stay  until  end  of  period. 

(7)  Block  L2500.  The  next  order  to  be  executed  by  the  unit  is 
stored  in  DST.  If  the  second  word  of  DST  is  less  than  zero,  it  is  a  relative 
time  and  must  have  TCLOCK  added  to  it. 

(8)  Block  4.  Orders  for  a  force  are  not  necessarily  executed  in 
input  sequence.  As  an  order  is  returned  to  FRCORD  for  processing,  its  first 
word  in  the  unit  scenario  is  set  to  zero;  therefore,  it  will  not  be  returned 
again. 


(9)  Block  L8000.  The  P  counter  for  the  unit  is  updated  and  restored 
in  unit  and  battle  directory  table  on  the  order  data  file. 

4.  ROUTINE  DBSR: 

a.  Purpose.  This  routine  determines  if  any  conditional  of  battle 
termination  has  been  met  and  returns  an  indicator.  If  it  has  been  met,  the 
P  counter  associated  with  each  participating  unit  is  set  to  the  order  to  be 
executed  after  battle  termination. 


b. 

Input  Variables: 

Name 

Source 

Contents 

BID 

Call 

Battle  identification. 

ORDFIL 

DSL 

DSL  data  file  number. 

BATPT 

DSL 

Pointer  to  first  battle  in  unit  and  battle 
directory  table. 

OUT 

DSL 

Logical  file  name  of  the  printer. 

UBT 

DF  ORDFIL 

Unit  and  battle  directory  table. 

OARY 

DF  ORDFIL 

Battle  scenario. 
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Output  Variables: 


c . 

Name  Destination  Contents 

IOVER  Call  Battle  completion  indicator: 

IOVER  =  1,  battle  is  completed. 

IOVER  =  0,  battle  is  not  completed. 

UBT  DF  ORDFIL  Unit  and  battle  directory  table. 

d.  Logical  Flow  (Figure  IV-18-B-2) : 

(1)  Block  L1010.  This  block  searches  the  unit  and  battle  directory 
*  table  for  the  battle  requested  (BID) ,  and  prints  an  error  message  if  it  is 

not  found.  If  it  is  found,  the  record  pointer  from  the  unit  and  battle 
directory  table  is  used  to  retrieve  the  battle  scenario  from  the  order  data 
file. 

(2)  Block  L3010.  The  battle  scenario  is  processed  to  determine  if 
any  of  the  conditions  that  terminate  the  battle  have  been  met.  If  a  termi¬ 
nating  condition  has  been  met,  control  is  transferred  to  block  L3020. 

(3)  Block  L4000.  IOVER  is  set  to  zero  indicating  the  battle  is  not 
completed  and  control  is  returned  to  the  calling  routine. 

(4)  Block  L3020.  IOVER  is  set  to  one  indicating  the  battle  will 
terminate,  and  the  list  of  participating  units  and  the  associated  P  counters 
are  stored.  The  portion  of  the  unit  and  battle  directory  table  applying  to 
units  is  brought  into  core. 

(5)  Blocks  L3055  and  L3060.  The  location  of  each  participating  unit 
is  found  in  the  unit  and  battle  directory  table  and  the  unit's  P  counter  is 
set  to  the  order  that  the  unit  is  to  execute  after  battle  termination. 

5 .  ROUTINE  BSUIDL : 
f 

*  a.  Purpose.  This  routine  returns  the  identification  of  units  parti¬ 

cipating  in  the  designated  battle  and  the  number  of  units  in  the  list. 


b.  Input  Variables: 


4 

Name 

Source 

Contents 

► 

ORDFIL 

DSL 

DSL  order  data  file  number. 

BATPT 

DSL 

Pointer  to  first  battle  in  unit  and  battle 
directory  table. 

* 

OUT 

DSL 

Logical  file  name  of  printer. 

BID 

Call 

Battle  identification. 

c 

UBT 

DF  ORDFIL 

Unit  and  battle  directory  table. 
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Figure  IV-18-B-2.  Routine  DBSR 
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Name 


Source 


Contents 


DF  ORDFIL  Participating  unit  list. 

Call  Total  number  of  units  in  battle  and  a  list 

of  each  UID. 

d.  Processing  Description.  This  routine  gets  the  unit  and  battle 
directory  table  (UBT)  into  core,  and  uses  it  to  locate  the  battle  scenario 
on  ORDFIL.  An  error  message  is  printed  if  it  cannot  be  found.  The  unit  and 
battle  directory  table  also  provides  the  total  number  of  units  in  this  battle 
that  is  stored  in  LIST(l).  The  UIDs  are  stored  in  reverse  order  beginning 
in  LIST (2) . 

6 .  ROUTINE  TRUTH : 


BAD 

LIST 


a.  Purpose.  This  routine  determines  if  a  DSL  conditional  clause  is  true 
or  false.  If  the  conditional  is  true,  a  logical  value  of  true  will  be 
returned;  otherwise,  a  false  value  will  be  returned. 


b. 

Name 

DOST 


Input  Variables: 

(1)  Standard  Common  Block  Area.  UMAIN. 

(2)  Other  Variables: 

Source  Contents 

Call  Variables  describing  the  conditional. 


c.  Output  Variables: 
Name  Source 


Contents 


TRUTH  Call  Logical  (.TRUE,  or  .FALSE.) 

d.  Logical  Flow  (Figure  IV-18-B-3) : 

(1)  Blocks  L75  and  1.  These  blocks  determine  the  type  of  conditional, 
and  the  appropriate  transfer  is  made. 


«  (2)  Blocks  L8,  L9,  and  L1Q.  These  blocks  are  the  transfer 

points  for  the  firing,  moving,  and  stopped  conditionals.  J  is  set  equal  to 
,  the  event  code  that  corresponds  to  the  type  of  the  conditional  and  D  is 
initialized. 

(3)  Block  L91 .  TRUTH  is  set  equal  to  D. 

*  (A)  Block  2.  GETEVT  is  called  to  retrieve  the  event  code  of  the 

unit . 

(5)  Blocks  3  and  L88.  If  the  event  code  (IE)  is  equal  to  J,  TRUTH 
£  is  set  opposite  to  its  initial  value. 
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Figure  IV-18-B-3.  Routine  TRUTH  (Continued) 
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Figure  IV- 18- B- 3.  Routine  TRUTH  (Continued) 
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Figure  IV-18-B-3.  Routine  TRUTH  (Continued) 
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Figure  IV-18-B-3.  Routine  TRUTH  (Continued) 
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Figure  IV-18-B-3.  Routine  TRUTH  (Concluded) 
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(6)  Blocks  LI  and  4.  If  NOT  is  equal  to  .TRUE.,  TRUTH  is  set 
opposite  to  its  initial  value. 


(7)  Blocks  5  and  6.  An  error  message  is  written  stating  the 
conditional  type  and  that  the  unit  does  not  exist.  TRUTH  is  set  equal  to 
.FALSE. . 

(8)  Block  L2.  This  block  is  the  entry  point  for  the  assessed 
conditional.  TRUTH  is  set  equal  to  .TRUE.. 

(9)  Block  L70.  If  the  unit  in  the  conditional  is  in  UMAIN,  the  time 
of  the  last  assessment  (LTASMT)  is  in  UMAIN. 

(10)  Blocks  7  and  8.  IUIDF  returns  the  index  of  the  unit.  If  the 
unit  does  not  exist,  control  transfers  to  block  5. 

(11)  Block  9.  Routine  GETWRD  returns  the  time  of  last  assessment. 

(12)  Blocks  L209  and  11.  If  the  unit  has  been  assessed  within  the 
last  15  minutes,  TRUTH  is  set  equal  to  .FALSE.;  control  then  goes  to  block  LI. 

(13)  Block  Lll.  This  block  is  the  entry  point  for  a  halted  at 
conditional.  TRUTH  is  set  equal  to  .FALSE.. 

(14)  Block  12.  If  the  unit  in  the  conditional  is  in  UMAIN,  the 
obstacle  facility  code  (OBFACC)  will  be  in  UMAIN;  and>  if  the  unit  is  in  UMAIN, 
control  goes  to  block  L201. 

(15)  Blocks  13  and  14.  IUIDF  returns  the  index  of  the  unit.  If  the 
unit  does  not  exist,  control  goes  to  block  5. 

(16)  Block  15.  Routine  GETWRD  returns  the  obstacle  facility  code. 

(17)  Blocks  L201  and  16.  If  the  obstacle  facility  code  is  less  than 
or  equal  to  zero,  TRUTH  is  set  equal  to  .TRUE.,  and  control  transfers  to 
block  LI. 

(18)  Block  L3.  This  block  is  the  entry  point  for  the  time  conditional. 
TRUTH  is  set  equal  to  .FALSE.. 

(19)  Block  17.  If  the  value  of  LOG  is  negative,  the  conditional  is 
less  than.  If  LOG  is  equal  to  zero,  it  is  an  equal  to  type  conditional.  If 
the  value  of  LOG  is  positive  the  conditional  is  a  greater  than  type. 

(20)  Blocks  18  and  23.  If  TCLOCK  is  less  than  CTIME;  TRUTH  is  set  equal 
to  .TRUE..  Control  goes  to  block  LI. 

(21)  Blocks  19  and  22.  If  TCLOCK  is  equal  to  CTIME,  TRUTH  is  set 
equal  to  .TRUE..  Control  goes  to  block  LI. 


(22)  Blocks  20  and  21.  If  TCLOCK  is  greater  than  CTIME,  TRUTH  is  set 
equal  to  .TRUE..  Control  goes  to  block  LI. 


(23)  Blocks  L1011  and  24.  This  is  the  entry  point  for  the 
present  strength  conditional.  If  the  unit  is  in  UMAIN,  control  goes  to 
block  28. 

(24)  Blocks  25  and  26.  IUIDF  returns  the  index  of  the  unit.  If  the 
unit  does  not  exist,  control  goes  to  block  5. 

(25)  Block  27.  Routine  GETWRD  returns  the  present  strength  of  the 

unit . 

(26)  Blocks  28  and  L204 .  PVAL  is  checked  to  determine  if  this  is  a 
percentage  type  conditional.  If  not,  control  goes  to  block  L68.  If  it  is, 
the  present  strength  is  divided  by  the  authorized  strength  to  compute  the 
present  strength  percentage. 

(27)  Block  L68.  This  block  determines  if  the  amount  of  the  unit's 
indicated  present  strength  is  to  be  compared  to  an  absolute  value  or  to  a 
percentage  of  the  unit's  authorized  strength.  The  comparison  is  made  and 
TRUTH  is  set  to  .TRUE,  or  .FALSE,  as  the  test  dictates.  Control  transfers  to 
block  LI. 


(28)  Block  80.  This  block  is  the  entry  point  for  the  following 
weather  conditionals:  Visibility  index,  cloud  cover,  temperature,  precipi¬ 
tation  index,  temperature  gradient,  relative  humidity,  wind  speed,  wiri 
direction,  and  fog  index.  J  is  set  to  the  value  that  corresponds  to  the 
weather  conditional  being  tested. 

(29)  Block  L31.  This  block  determines  whether  the  conditional  is  a 
location  or  unit  type.  If  XLOC  is  greater  than  zero,  it  is  a  location  type 
and  control  goes  to  L750.  If  XLOC  is  equal  to  or  less  than  zero,  it  is  a 
unit  type  conditional;  control  goes  to  block  35. 

(30)  Block  L750.  The  coordinates  X  and  Y  are  set  for  a  location 
type  conditional,  and  control  goes  to  block  L211. 

(31)  Blocks  35,  36,  and  37.  If  the  unit  is  not  in  UMAIN,  IUIDF  returns 
the  index  of  the  unit.  If  the  unit  does  not  exist,  control  goes  to  block  5. 

(32)  Block  38.  Routine  GETWRD  returns  the  location  of  the  unit. 

(33)  Block  L1015.  X  and  Y  coordinates  are  set  equal  to  XACT  and 

YACT. 

(34)  Block  L211.  If  the  weather  sector  is  in  common,  control  goes 
to  block  L202;  if  not,  control  goes  to  L205. 

(35)  Blocks  L2Q5  and  L202.  The  weather  parameter  is  obtained  from 
IOWETH  if  the  weather  sector  is  not  in  common. 

(36)  Block  39.  The  weather  parameter  in  the  conditional  is  compared 
with  the  actual  weather  parameter  and  TRUTH  is  set  to  .TRUE,  or  .FALSE,  as 
the  test  dictates.  Control  goes  to  block  LI. 
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(37)  Block  L4.  This  block  is  the  entry  point  for  the  at  location 
type  conditional.  TRUTH  is  set  equal  to  .FALSE.. 

(38)  Block  42.  If  the  unit  is  in  UMAIN,  control  goes  to  block  L83; 
if  not,  control  goes  to  block  43. 

(39)  Blocks  43  and  44.  IUIDF  returns  the  index  of  the  unit.  If  the 
unit  does  not  exist,  control  goes  to  block  5;  otherwise,  control  goes  .o 
block  L83. 

(40)  Block  L83.  GETEVT  returns  the  event  code  of  the  unit. 

(41)  Block  45.  If  the  unit  is  in  UMAIN,  control  goes  to  block  L1013; 
if  not  control  goes  to  block  46. 

(42)  Blocks  46  and  L1013.  The  dimensions  and  orientation  are 
obtained  from  the  unit  status  record. 

(43)  Blocks  L200  and  47.  The  unit's  event  code  is  checked  to 
determine  if  the  unit  is  moving.  If  not,  control  goes  to  block  50;  if  it  is, 
control  appropriately  goes  to  block  49  (unit  in  UMAIN)  or  block  48  (unit  not 
in  UMAIN). 

(44)  Blocks  48  and  49.  The  unit’s  objective  coordinates  die 
obtained,  and  control  goes  to  block  L84. 

(45)  Block  L84 .  This  block  determines  the  unit's  actual  location 
of  a  moving  unit. 

(46)  Blocks  50  and  51.  A  check  determines  if  the  locations  overlap. 
If  they  do,  TRUTH  is  set  equal  to  .TRUE.,  and  control  goes  to  block  LI. 

(47)  Block  L100.  This  block  is  the  entry  point  for  class  III, 
class  V,  and  equipment  type  conditionals.  Determine  if  the  unit  is  in  UMAIN. 
If  so,  control  goes  to  block  L1000;  if  not,  control  goes  to  block  52. 

(48)  Block  L1000.  The  amount  of  the  equipment  on  hand  is  acquired 
from  UMAIN.  Control  goes  to  block  53. 

(49)  Blocks  52  and  54.  The  index  of  the  unit  is  obtained  by  calling 
IUIDF.  This  index  is  checked  to  determine  if  the  unit  exists.  If  not, 
control  transfers  to  block  5. 

(50)  Block  55.  A  call  to  GETWRD  returns  the  amount  of  equipment 

on  hand. 

(51)  Blocks  53  and  56.  A  check  determines  if  the  conditional  is  a 
percentage  type.  If  not,  control  goes  to  block  L5000. 

(52)  Block  L200.  A  call  to  GETWRD  returns  the  amount  of  equipment 
authorized. 
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(53)  Block  57.  The  percentage  value  is  calculated  by  dividing  the 
amount  of  equipment  on  hand  by  the  amount  of  equipment  authorized. 

(54)  Blocks  L500C,  58,  and  59.  UNTLOC  is  checked  to  determine  if 
the  unit  is  a  resolution  unit.  If  it  is  not,  an  error  message  is  written, 
TRUTH  is  set  equal  to  .FALSE.,  and  control  returns  to  the  calling  routine. 
If  sc,  control  goes  to  block  60. 

(55)  Block  60.  This  block  determines  if  the  amount  of  the  unit's 
indicated  equipment  item  is  to  be  compared  to  an  absolute  value  or  to  a 
percentage  of  the  unit's  authorized  quantity  of  that  equipment  item.  The 
percentage  is  calculated  if  necessary,  a  comparison  is  made,  and  TRUTH  is 
set  to  .TRUE,  or  -FALSE,  as  the  test  dictates.  Control  goes  to  block  LI. 
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OUTPUT  DESCRIPTIONS  FOR  DIVWAG  SCENARIO  LANGUAGE  INTERFACE  ROUTINES 


The  printed  output  produced  by  the  DIVWAG  scenario  language  (DSL)  interface 
routines  is  shown  in  Figure  IV-18-C-1  and  is  described  below. 


Output 

Descriptor 

A 


B 


Explanation 

This  message  indicates  no  unit  scenario  was  written  for  the 
unit  whose  unit  identification  is  listed.  It  usually  occurs 
at  time  zero  when  the  next  order  is  requested  for  each 
resolution  unit.  This  statement  occurs  in  routine  DOSR. 

This  printout  lists  IOVER  which  indicates  the  status  of  the 
battle  named.  If  IOVER  equals  zero  the  battle  is  not  to  be 
terminated;  if  IOVER  equals  one  a  condition  of  termination 
was  met.  This  statement  occurs  in  routine  DBSR  and  is 
controlled  by  print  switch  2. 
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CHAPTER  19 


UTILITY  ROUTINES 


1.  INTRODUCTION.  This  chapter  contains  the  descriptions  of  the  utility 
routines  of  the  Period  Processor.  These  routines  are  generally  characterized 
by  their  small  size  and  the  fact  that  they  are  used  by  more  than  one  model  or 
by  the  executive  control  routines. 

2.  ORGANIZATION.  The  utility  routines  are  grouped  functionally  into  the 
following  categories. 

a.  Real-time  Clock.  Routines  which  provide  the  running  and  restart  times 
used  by  the  executive  control. 

b.  Geometric  Calculations.  Routines  which  calculate  angles,  intersection 
points  and  distances. 

c.  Location-related  Calculations.  Routines  which  return  lists  of  terrain 
cells  or  units  in  a  designated  area  and  line  of  sight. 

d.  Numeric  Operations.  Routines  which  perform  common  arithmetic  operations. 

e.  Specialized  Processing.  Routines  which  perform  specialized  functions 
required  in  the  Period  Processor. 

f.  Extended  Storage.  Routines  which  provide  access  to  data  file  16 
(formerly  chapter  two  common). 

g.  General  Assessment  Bookkeeping.  Routines  which  perform  secondary 
assessment,  produce  assessment  history  records,  and  maintain  unit  score  boards. 
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APPENDIX  A 


INPUT  REQUIREMENTS  FOR  UTILITY  ROUTINES 


Input  to  all  utility  routines  is  passed  through  the  call  or  in  common 
No  special  input  data  are  required.  The  reader  is  referred  to  the  descrip 
tion  of  the  calling  routines  for  sources  of  data. 
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APPENDIX  B 


UTILITY  PROGRAM  DESCRIPTIONS 


1.  INTRODUCTION.  Utility  routines  within  the  DIVWAG  Period  Processor  are 
described  in  this  appendix.  The  routines  are  grouped  into  a  related  processing 
function  or  association  as  follows: 

a.  Real-time  Clock..  SETCLK,  MINGET,  and  REDCLK. 

b.  Geometric  Calculations.  ARCTAN,  CHORD,  DISTPL,  DSTPL1,  INTSPT,  and 
PONTLN . 

c.  Location  Related  Calculations.  CELLST,  LOS,  and  SEARCH. 

d.  Numeric  Orientation  and  Random  Numbers.  INTPOL,  RANGEF,  RANKA,  RANK, 
SCALE,  DNORM,  ENORM,  FNORM,  RANDU,  and  RANDl. 

e.  Specialized  Processing.  IUIDF,  ADDUNT,  BUFFIN,  BUFOUT,  KPICK,  and 
BLKDAT . 

f.  Access  to  Data  File  16.  GET  and  PUT. 

g.  General  Assessment  Bookkeeping.  E0H20T,  PUTOUT,  and  SCORE. 

2.  ROUTINE  SETCLK.  This  routine  sets  the  variable  MINST  (period  start  time 
in  minutes)  to  the  current  wall  clock  time.  It  is  called  only  once  (during 
initialization)  for  each  gaming  simulation  run. 

3.  ROUTINE  MINGET.  This  routine  translates  the  wall  clock  time,  that  is 
returned  from  the  system  library  routine  TIME  in  character  hours,  minutes, 
and  seconds,  into  integer  minutes.  The  seconds  are  ignored. 

4.  ROUTINE  REECLK.  REDCLK  obtains  the  current  wall  clock  time,  in  minutes, 
from  MINGET.  If  the  current  time  is  less  than  a  previously  set  criterion 
(MINST,  representing  period  start  time),  the  current  time  is  incremented 
one  day  (1440  minutes).  REDCLK  returns  the  difference  between  current  wall 
clock  time  and  period  start  time  (MINST) . 

5.  ROUTINE  ARCTAN: 

a.  Purpose.  This  routine  determines  the  angle  and  its  quadrant  between 
a  local  origin  and  a  point  with  coordinates  X  and  Y  from  that  origin.  The 
angle  is  measured  counterclockwise  from  the  positive  X  direction,  in  radians, 
between  0.0  and  2  r.  The  quadrant  is  signified  by  an  integer  variable. 


b.  Input  Variables: 


Name 

Source 

Contents 

DELX 

Call 

X  coordinate  of  point  minus  X  coordinate  of 
local  origin. 
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Name 


Source 


Content 


DELY  Call 

c.  Output  Variables: 
Name  Destination 

RAD  Call 

I QUAD  Call 


Y  coordinate  of  point  minus  Y  coordinate  of 
local  origin. 


Contents 

Angle  in  radians. 
Quadrant  indicator. 


d. 

collocated 


Processing  Description, 
ed  (within  10-8  meters) 


If  the  point  and  the  origin  are  essentially 
the  quadrant  indicator  is  assigned  a  value  of 


nine  and  the  angle  is  set  to  zero.  If  DELX  is  essentially  zero  (within  10 


-8 


meters)  and  if  DELY  is  positive,  RAD  is  set  to  1.5707963  (90°)  and  IQUAD  is 
set  to  six;  if  DELY  is  negative,  RAD  is  set  to  4.7123890  (270°)  and  IQUAD  is 
set  to  eight.  If  DELY  is  essentially  zero  (within  10“8  meters)  and  if  DELX 
is  positive,  RAD  is  set  to  zero.  (0°)  and  IQUAD  is  set  to  five;  if  DELX  is 
negative,  RAD  is  set  to  3.1415927  and  IQUAD  is  set  to  seven.  In  all  other 
cases,  the  system  library  routine  ATAN  is  used  to  compute  the  angle,  between 
zero  and  positive  or  negative  *72,  within  the  quadrant.  From  the  signs  of 
DELX  and  DELY,  the  quadrant  is  determined,  and  IQUAD  is  set  accordingly. 

If  IQUAD  is  equal  to  one  (first  quadrant) ,  RAD  is  set  to  the  value  returned 
by  the  library  routine.  If  IQUAD  is  equal  to  two  or  three  (second  or  third 
quadrants),  RAD  is  set  to  the  angle  returned,  plus  rr.  If  IQUAD  is  eq.  il  to 
four,  RAD  is  set  to  the  angle  returned,  plus  2jt. 


6.  ROUTINE  CHORD: 


a.  Purpose.  This  routine  determines  the  X  coordinates  of  intersection 
or  tangency,  if  any,  of  a  line  and  a  circle. 

b.  Input  Variables: 

Name  Source  Contents 


xc 

Call 

X  coordinate  of 

center  of 

circle. 

YC 

Call 

Y  coordinate  of 

center  of 

circle. 

R 

Call 

Radius  of  the  circle. 

XI 

Call 

X  coordinate  of 

point  1  on 

line. 

Y1 

Call 

Y  coordinate  of 

point  1  on 

line. 

X2 

Call 

X  coordinate  of 

point  2  on 

line. 

Y2 

Call 

Y  coordinate  of 

point  2  on 

line. 
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c.  Output  Variables: 


Name 

XC1 

XC2 


Destination 

Call 

Call 


Contents 

X  coordinate  of  intersection  point 
X  coordinate  of  intersection  point 


1. 


2. 


d.  Processing  Description.  The  equations  of  the  line  and  the  circle 
are  formed.  The  intersections  of  the  line  and  the  circle  are  then  solved  by 
the  quadratic  equation.  If  no  intersection  or  tangency  exists,  both  output 
variables  are  zero.  If  the  line  is  tangent,  or  if  the  line  is  due  north- 
south,  the  two  output  variables  are  equal. 


7.  ROUTINE  DISTPL: 


a.  Purpose.  This  routine  computes  the  perpendicular  distance  from  a 
line  to  a  point.  The  line  is  defined  by  two  points. 

b.  Input  Variables: 

Name  Source  Contents 


XI 

Call 

X 

coordinate 

of 

point  1  on  line. 

Yl 

Call 

Y 

coordinate 

of 

point  1  on  line. 

X2 

Call 

X 

coordinate 

of 

point  2  on  line. 

Y2 

Call 

Y 

coordinate 

of 

point  2  on  line. 

XO 

call 

X 

coordinate 

of 

point . 

YO 

Call 

Y 

coordinate 

of 

point. 

c. 

Output  Variables: 

Name 

Destination 

Contents 

PDIST 

Call 

Perpendicular  distance  from  line  to  point. 

d. 

Logical  Flow.  The  slope  of  the  line 

is 

calculated .  The  coordinates 

of  the  independent  point  and  a  point  on  the  line  are  combined  with  the  slope 
of  the  line  in  the  standard  equation  for  calculating  distance  between  a 
point  and  a  line  with  slope  M: 


PDISX  _  M(XO  -  XI)  -  (YO  -  Yl) 

Vm*  +  l 


(IV-19-B-1) 
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8. 


ROUTINE  DSTPL1 : 


a.  Purpose.  This  routine  computes  the  perpendicular  distance  from  a  line 
to  a  point.  The  line  is  defined  by  one  point  and  a  slope. 


b. 

Input 

Variables : 

Name 

Source 

Contents 

XI 

Call 

X  coordinate  of  point  1  on  line. 

Yl 

Call 

Y  coordinate  of  point  1  on  line. 

X2 

Call 

Slope  of  line. 

Y2 

Call 

Dummy  variable. 

XO 

Call 

X  coordinate  of  point. 

YO 

Call 

Y  coordinate  of  point. 

c. 

Output 

Variables : 

Name 

Destination 

Contents 

PDIST 

Call 

Perpendicular  distance  from  line  to  point 

d.  Logical  Flow.  The  slope  of  the  line  is  returned  as  a  parameter.  The 
coordinates  of  the  independent  point  and  the  point  on  the  line  are  combined 
with  the  slope  of  the  line  in  the  standard  equation  for  calculating  the 
distance  between  a  point  and  a  line  with  slope  M: 


FOIST  „  M(X0  -  XI)  -  (YO  -  Yl) 

\/m2  +  1 
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9.  ROUTINE  INTSPT : 

a.  Purpose.  This  routine  finds  the  coordinates  of  an  intersection  of 
two  line  segments  in  the  X,Y  plane. 

b.  Input  Variables: 

Name  Source  Contents 


XI 

Call 

X 

coordinate 

of 

cart  of 

line 

segment 

1. 

Yl 

Call 

Y 

coordinate 

of 

start  of 

line 

segment 

1. 

IV-19-B-4 


Name 

Source 

Contents 

X2 

Call 

X  coordinate  of 

end  of  line  segment  1. 

Y2 

Call 

Y  coordinate  of 

end  of  line  segment  1. 

X3 

Call 

X  coordinate  of 

start  of  line  segment 

2. 

Y3 

Call 

Y  coordinate  of 

start  of  line  segment 

2. 

X4 

Call 

X  coordinate  of 

end  of  line  segment  2. 

Y4 

Call 

Y  coordinate  of 

end  of  line  segment  2. 

c. 

Output  Variables: 

Name 

Destination 

Contents 

XPT 

Call 

X  coordinate  of 
line  segments. 

intersection  point  of 

two 

YPT 

Call 

Y  coordinate  of 
line  segments. 

intersection  point  of 

two 

NOT 

Call 

Intersection  flag:  1  =  no  intersection. 

=  intersection. 

d.  Logical  Flow  (Figure  IV-19-B-1) : 

(1)  Block  1.  The  slope  of  each  line  is  generated  from  the  coordinates 
defining  each  line  segment. 

(2)  Block  2.  The  slopes  of  the  two  lines  are  compared.  If  both 
lines  are  due  north-south,  the  slope  test  is  not  made,  since  the  slopes  must 
be  equal.  Similarly,  if  one  line  is  due  north-south  and  the  other  is  not, 
the  slope  test  is  not  made,  since  the  slopes  cannot  be  equal.  If  slopes 
are  equal,  control  goes  to  block  L100. 

(3)  Block  3.  Calculate  the  X  coordinate  of  intersection  of  the  two 
lines;  the  X  coordinate  is  solved  by  combining  the  equations  of  both  lines. 

The  Y  coordinate  is  calculated  from  the  equation  of  the  appropriate  line. 

(4)  Block  4.  Since  the  coordinates  obtained  for  intersection  of 
the  two  lines  may  not  lie  within  the  two  line  segments,  tests  are  made  to 
accept  only  an  intersection  of  the  line  segments.  If  not  on  the  lines, 
control  goes  to  block  L100. 

(5)  Block  L250.  If  the  line  segments  intersect,  NOT  is  given  the 
value  of  two. 

(6)  Block  L100.  If  the  line  segments  do  not  intersect,  NOT  is  given 
the  value  one. 
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Figure  IV-19-B-1.  Routine  INTSPT 
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10.  ROUTINE  PONTLN : 

a.  Purpose.  This  routine  calculates  the  distance  between  a  point  and 
a  line  segment.  If  the  point  is  in  the  region  between  the  ends  of  the  line 
segment,  the  distance  is  perpendicular  to  the  line  segment;  otherwise,  the 
distance  is  to  the  nearest  end  of  the  line  segment.  An  output  variable 
quantifies  the  position  of  the  point  relative  to  the  start  and  end  of  the 
line  segment . 


b. 

Input 

Variables : 

Name 

Source 

Contents 

PT1X 

Call 

X 

coordinate  of  start  of  line  segment. 

PT1Y 

Call 

Y 

coordinate  of  start  of  line  segment. 

PT2X 

Call 

X 

coordinate  of  end  of  line  segment. 

PT2Y 

Call 

Y 

coordinate  of  end  of  line  segment. 

PT3X 

Call 

X 

coordinate  of  independent  point. 

PT3Y 

Call 

Y 

coordinate  of  independent  point. 

c. 

Output 

Variables : 

Name 

Destination 

Contents 

SEP 

Call 

Distance  between  point  and  line  segment 

THAD 

Call 

Relative  position  on  the  line  extending 

through  the  line  segment  of  a  point  subtended 
perpendicularly  by  the  independent  point. 

d.  Logical  Flow  (Figure  IV-19-B-2) : 

(1)  Block  1.  If  the  coordinates  of  point  2  equal  zero,  there  is 
no  second  point.  If  nonzero,  control  goes  to  block  3. 

(2)  Block  2.  The  distance  between  point  1  and  point  3  is  calculated 
by  the  differences  in  coordinates,  then  return  control  to  the  calling  routine. 

(3)  Block  3.  THAD  is  calculated.  If  the  value  of  THAD  is  negative, 
the  independent  point  lies  beyond  the  start  (point  1)  of  the  line  segment, 
and  control  goes  to  block  2.  In  this  case  the  value  of  THAD  is  the  negative 
quotient  of  SEP  divided  by  the  length  of  the  line  segment. 

(4)  Block  4.  If  the  value  of  THAD  is  greater  than  one, the  independent 
point  lies  beyond  the  end  (point  2)  of  the  line  segment,  and  control  goes  to 
block  5.  In  this  case,  the  value  of  THAD  is  one  plus  the  quotient  of  SEP 
divided  by  the  length  of  the  line  segment. 
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Figure  IV-19-B-2.  Routine  PONTLN 
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(5)  Block  5.  The  distance  between  point  2  and  point  3  is  calculated, 
and  control  returns  to  the  calling  routine. 

(6)  Block  6.  Since  the  independent  point  lies  in  the  region  between 
the  ends  of  the  line  segment,  THAD  is  the  fractional  distance  along  the 

line  segment,  from  point  1,  of  a  point  subtended  perpendicularly  by  the 
independent  point.  This  fraction,  applied  to  the  distance  between  point  1 
and  point  2,  provides  a  side  of  the  triangle;  the  distance  between  point  1 
and  point  3  provides  the  hypotenuse.  The  desired  perpendicular  distance  is 
the  third  side  of  this  right  triangle. 

11.  ROUTINE  CELLST: 

a.  Purpose.  This  routine  generates  a  list  of  terrain  cells  penetrated 
by  a  line  segment  defined  by  the  coordinates  XI, Y1  and  X2,Y2. 

b.  Input  Variables: 


Name 

Source 

Contents 

XI 

Call 

Initial  X  coordinate 

of  line  segment. 

Y1 

Call 

Initial  Y  coordinate 

of  line  segment. 

X2 

Call 

Ending  X  coordinate 

of  line  segment. 

Y2 

Call 

Ending  Y  coordinate 

of  line  segment. 

NTERR 

ONE 

Terrai..  cell  size. 

NXTC 

ONE 

X  dimension  of  map  square  defined  by  terrain 
cells. 

c.  Output  Variables: 


Name 

Destination 

Contents 

LIST(IOO) 

Call 

Array  of  terrain  cell  identification  numbers. 

NCELLS 

Call 

The  number  of  whole  cells  between  coordinate 
origin  and  point  2. 

d.  Logical  Flow  (Figure  IV-19-B-3) : 

(1)  Block  1.  The  number  of  cells  defined  on  the  map,  in  the  X 
direction  is  the  X  distance  over  which  cells  are  defined  divided  by  the 
size  of  a  single  cell. 

(2)  Block  2.  The  number  of  whole  cells  between  the  X,Y  coordinate 
origin  and  the  initial  point  on  the  line  segment  (point  1)  is  determined  for 
each  of  the  X  and  Y  directions  by  dividing  the  coordinate  value  by  the  size 
of  a  cell  and  truncating  any  fraction. 
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Figure  IV-19-B-3.  Routine  CELLST  (Continued  on  Next  Page) 
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Figure  IV-19-B-3.  Routine  CELLST  (Concluded) 
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(3)  Block  3.  The  identif ication  number  of  the  cell  containing  point  1 
is  determined  from  the  cell  size,  the  number  of  cells  defined  in  the  map  in 
the  X  direction,  and  the  number  of  whole  cells  between  the  origin  and  point  1 
by  the  expression: 


ID  =  NX  *  IY  +  IX  +  2 


(IV-19-B-3) 


where: 


ID  =  identification  of  first  cell,  stored  in  LIST(l) 

NX  =  number  of  cells  defined  on  the  map  in  the  X  direction 
(determined  in  block  1) 

IY  =  number  of  cells  in  Y  direction  between  point  1  and  coordinate 
origin  (determined  in  block  2) 

IX  =  number  of  cells  in  X  direction  between  point  1  and  coordinate 
origin  (determined  in  block  2). 

(4)  Block  4.  Point  2  is  the  ending  point  of  the  line  segment.  The 
number  of  whole  cells  in  X  and  Y  is  determined  as  in  block  2. 

(5)  Block  5.  The  boundaries  of  the  cell  currently  being  considered 
are  determined  from  the  cell  size  and  the  number  of  cells  between  the  current 
point  and  the  coordinate  origin. 

(6)  Block  6.  Routine  INTSPT  determines  whether  the  line  between 
the  current  point  and  point  2  penetrates  a  given  boundary  of  the  current 
cell  and,  if  so,  the  coordinates  of  the  point  of  intersection.  The  sides 
of  the  cell  are  selected  one-at-a-time  until  the  intersection  is  found. 

(7)  Block  7.  The  coordinates  of  intersection  just  found  are 
adjusted  slightly  in  the  direction  of  point  2  so  that  the  adjusted  point  lies 
within  the  next  terrain  cell  along  the  line  segment. 

(8)  Block  8.  The  number  of  whole  cells  between  the  coordinate 
origin  and  the  current  point  are  calculated  (in  the  same  manner  as  in  block  2). 

(9)  31ock  9.  The  identification  number  of  the  cell  containing  the 
current  point  is  determined  (in  a  manner  similar  to  that  in  block  3)  and 
entered  in  LIST. 

(10)  Block  10  and  11.  The  number  of  whole  ceils  between  coordinate 
origin  and  point  2  is  compared  with  the  corresponding  number  for  the  current 
point.  If  equal,  return  control  to  the  calling  routine;  otherwise,  control 
goes  to  block  11  to  search  for  the  next  cell. 


IV-19-B-12 


12.  ROUTINE  LOS: 


a.  Purpose.  This  routine  determines  whether  line  of  sight  exists  between 
a  point  specified  by  X,  Y,  Z  coordinates  and  the  center  of  a  unit  being 
considered  by  the  calling  routine. 

b.  Input  Variables: 

Name  Source  Contents 

IFLAG  Call  Flag  to  locate  unit  status  record:  0  =  UMAIN, 


1  -  UCOOP. 


X 

Call 

X 

coordinate 

of 

specified 

point. 

Y 

Call 

Y 

coordinate 

of 

specified 

point. 

Z 

Call 

Z 

coordinate 

of 

specified 

point. 

XACT 

or 

CXACT 

ONE 

X 

coordinate 

of 

center  of 

unit  of 

interest. 

YACT 

or 

CYACT 

ONE 

Y 

coordinate 

of 

center  of 

unit  of 

interest. 

ZACT 

or 

CZACT 

ONE 

Z 

coordinate 

of 

center  of 

unit  of 

interest. 

MASKF  or  CMASKF  ONE  Array  containing  range  and  elevation  angle 

to  dominant  mask  each  15° in  azimuth  around 
center  of  unit  (24  angles). 


c.  Output  Variables: 

Name  Destination  Contents 

LOS  Call  Line  of  sight  parameter:  0  *  no,  1  •  yes 

d.  Logical  Flow  (Figure  IV-19-B-4) : 

(1)  Block  1.  The  input  IFLAG  indicates  whether  the  unit  of  interest 
is  in  UMAIN  or  UCOOP,  to  obtain  the  correct  unit  center  coordinates  and 
dominant  mask  function. 

(2)  Blocks  2  and  L20.  Unit  center  coordinates  and  dominant  mask 
data  are  obtained  for  the  unit  being  considered  by  the  calling  routine. 

(3)  Block  L40.  The  line-of-sight  parameter  is  initialized  to 
indicate  no  line  of  sight. 

(4)  Block  L100.  The  azimuth  from  unit  center  to  input  point  is 
computed  and  reduced  to  lower  and  upper  azimuth  indexes,  that  specify  the  15s 
sector  containing  the  point,  and  the  fractional  position  of  the  point  within 
that  sector. 
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Figure  IV-19-B-4. 


Routine  LOS  (Continued  on  Next  Page) 
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Figure  IV-19-B-4.  Routine  LOS  (Concluded) 
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(5)  Blocks  3  and  4.  If  the  unit  center  and  input  point  coincide, 
set  LOS  equal  to  one,  and  return  control  to  the  calling  routine. 

(6)  Block  L200.  The  horizontal  range  from  the  unit  center  to 

the  terrain  mask  at  the  computed  azimuth  is  obtained  by  interpolation  between 
the  ranges  obtained  from  mask  data  for  each  edge  of  the  15°  sector  containing 
the  point. 

(7)  Block  5.  The  horizontal  range  from  the  unit  center  to  the 
input  point  is  computed  from  the  X  and  Y  coordinates . 

(8)  Blocks  6  and  7.  The  horizontal  range  from  unit  to  point  is 
compared  with  the  horizontal  range  from  unit  to  mask.  If  the  point  is 
within  mask  range,  line  of  sight  exists.  Set  LOS  equal  to  one  and  return 
control  to  the  calling  routine;  otherwise,  continue  processing  at  block  L1300. 

(9)  Block  L300.  The  angular  elevation  of  the  input  point  is 
calculated  by  the  difference  between  Z  coordinates  of  the  point  and  the  unit 
and  the  horizontal  distance  from  point  to  unit. 

(10)  Block  8.  The  terrain  mask  angle,  for  the  computed  azimuth  of 
the  point,  is  interpolated  from  the  mask  angles  of  the  upper  and  lower  azimuth 
indexes  of  the  sector  containing  the  point. 

(11)  Block  9  and  10.  The  elevation  angle  of  the  point  is  compared 
with  the  mask  angle.  If  point  elevation  angle  exceeds  mask  angle,  line  of 
sight  exists  and  LOS  is  set  to  one.  Return  control  to  the  calling  routine. 

13.  ROUTINE  SEARCH: 

a.  Purpose.  This  routine  returns  a  list  of  enemy  resolution  units 
that  are  located  within  a  specified  radius  of  a  given  point.  For  moving 
units,  the  specified  radius  is  increased  by  the  diagonal  distance  of  one 
terrain  cell.  The  number  of  units  on  the  list  is  also  provided. 

b.  Input  Variables: 


Name 

Source 

Contents 

UID 

Call 

Identification  of  the  unit  requesting  the 
search. 

X 

Call 

X  coordinate  of  the  center  of  the  area  to  be 
searched. 

Y 

Call 

Y  coordinate  of  the  center  of  the  area  to  be 
searched. 

S 

Call 

Radius  of  search  about  the  center. 

JMAX 

Call 

Maximum  number  of  enemy  units  to  be  listed. 
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Name 

Source 

Contents 

BPOINT 

ONE 

Index  of  last  Blue  unit. 

RPOINT 

ONE 

Index  of  first  Red  unit. 

NTERR 

ONE 

Terrain  cell  dimension. 

ICOORD 

ONE 

Coordinates  of  a  resolution  unit. 

I EVENT 

ONE 

Event  code  of  a  resolution  unit. 

c. 

Output  Variables: 

Name 

Destination 

Contents 

UNTLST 

Call 

List  of  enemy  units  found. 

J 

Call 

Total  number  of  units  in  UNTLST. 

d.  Logical  Flow  (Figure  IV-19-B-5): 

(1)  Block  1.  The  inner  radius  of  search  is  the  specified  input 
value.  The  outer  radius  includes  one  terrain  cell's  diagonal  distance  to 
ensure  a  listing  of  moving  units  of  which  coordinates  have  not  been  updated. 

(2)  Block  2.  The  first  character  of  the  unit  identification  is  used 
to  determine  if  the  unit  requesting  search  is  Red  or  Blue.  The  index  limits 
for  opposing  units  are  established  accordingly,  utilizing  BPOINT  or  RPOINT. 
The  search  loop  considers  each  opposing  unit. 

(3)  Block  3.  The  X  and  Y  coordinates  of  an  enemy  unit  are  returned 
by  ICOORD  to  calculate  distance  from  the  center  of  the  search  area. 

(4)  Block  4.  If  the  distance  exceeds  the  outer  search  radius,  the 
next  enemy  unit  is  processed. 

(5)  Block  5.  The  event  code  of  the  enemy  unit  is  checked.  If  the 
unit  is  moving,  control  goes  to  block  7. 

(6)  Block  6.  Since  the  unit  is  not  moving,  it  must  be  within  the 
inner  radius  of  search  to  be  added  to  the  list. 

(7)  Block  7.  If  the  list  already  contains  the  specified  maximum 
number  of  units,  a  message  is  printed  before  control  returns  to  the  calling 
routine. 

(8)  Block  8.  The  enemy  unit  is  added  to  the  list. 

(9)  Block  9.  If  all  enemy  units  have  been  considered,  control 
is  returned  to  the  calling  routine. 
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14.  ROUTINE  INTPOL: 


a.  Purpose.  This  routine  performs  linear  interpolation,  within  an 
input  table,  to  generate  Y  as  a  function  of  a  given  X  value.  The  input 
table  specifies  a  value  of  Y  for  each  implicit  X  value  entry  up  to  21,  assumed 
equally  spaced. 


b. 

Input  Variables: 

Name 

Source 

Contents 

X 

Call 

Given  X  value  for  which  Y  value  is  sought. 

FIRSTX 

Call 

X  value  of  the  first  entry  in  the  table. 

STPSIZ 

Call 

X  distance  (assumed  constant)  between  entries 
in  the  table. 

NENTRI 

Call 

Total  number  of  entries  in  the  table. 

TABLE 

Call 

Name  and  first  location  of  the  table. 

c. 

Output  Variables: 

Name 

Destination 

Contents 

Y  Call  Y  value  interpolated  for  given  X  value, 

d.  Logical  Flow  (Figure  IV-19-B-6): 

(1)  Block  1.  The  position  of  the  given  X  value  is  established  in 
fractional  steps,  relative  to  the  X  value  of  the  first  entry  in  the  table. 

(2)  Block  2.  The  position  of  X,  in  integral  steps,  is  the  fractional 
position  adjusted  and  truncated. 

(3)  Block  3.  If  the  fractional  position  is  negative,  X  is  outside 
the  X  value  of  the  first  entry  in  the  table.  If  the  fractional  position 

is  zero,  X  is  equivalent  to  the  X  value  of  the  first  entry  in  the  table.  In 
both  cases,  the  entries  on  either  side  of  X  are  the  first  table  entry.  If 
the  integral  step  position  of  X  equals  or  exceeds  the  total  number  of  entries 
in  the  table,  NENTRI,  the  last  entry  is  assumed  to  be  the  entries  on  either 
side  of  X;  otherwise,  the  entries  on  either  side  of  X  are  different,  based 
on  the  integral  step  position  of  X. 

(4)  Block  4.  The  interpolated  value  of  Y  is  the  lower  side  table 
entry  plus  the  same  fraction  of  the  difference  between  lower  and  upper  side 
entry  as  the  fractional  position  of  X  within  the  X  interval  between  these 
two  entries. 


Figure  IV-19-B-6.  Routine  INTPOL 
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15.  ROUTINE  RANGEF: 


a. 

Purpose.  This  routine 

calculates  the  distance  between  two  points 

in  the 

X,Y  plane. 

b. 

Input  Variables: 

Name 

Source 

Contents 

XI 

Call 

X 

coordinate  of  point  1. 

Y1 

Call 

Y 

coordinate  of  point  1. 

X2 

Call 

X 

coordinate  of  point  2. 

Y2 

Call 

Y 

coordinate  of  point  2. 

c. 

Output  Variables: 

Name 

Destination 

Contents 

RANGEF 

Call 

Distance  between  point  1  and  point  2. 

d. 

Processing  Description, 

This  function  takes  the  square  root  of 

the  sum  of  the  squares  of  the  differences  in  coordinates  between  the  two 
points. 

16.  ROUTINES  RANKA  and  RANK: 

a.  Purpose.  These  routines  consider  the  values  from  a  one-dimensional 
array  of  up  to  36  items  and  generates  a  list  of  the  index  numbers  of  the 
input  array  arranged  in  order  with  the  smallest  array  value  first  and  the 
greatest  last.  Two  versions  of  this  routine  exist.  Routine  RANKA  has  input 
and  output  variables  defined  as  calling  parameters.  The  other  version,  routine 
RANK  is  identical  except  that  input  and  output  variables  are  located  in 
common. 


b.  Input  Variables: 

Name  Source 

A  Call  or  TWO 

II  Call  or  TWO 

c.  Output  Variables: 

Name  Destination 

1PT  Call  or  TWO 


Contents 


Array  of  values  to  be  ranked. 
Number  of  items  in  the  array. 


Contents 


List  of  index  numbers  of  array  items  ranked 
in  decreasing  order  of  array  value. 
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d.  Logical  Flow  (Figure  IV-19-B-7): 

(1)  Block  1.  To  find  the  smallest  or  most  negative  value  in  the 
input  array,  the  input  values  are  resigned  and  placed  in  a  resigned  value 
array  (D) .  Each  value  in  the  resigned  array  is  compared. 

(2)  Block  2.  The  index  number  of  the  smallest  or  most  negative 
value  in  the  resigned  array  (same  index  as  input  array)  is  placed  in  the 
Kth  place  in  the  output  list,  proceeding  from  one  through  the  total  number 
of  array  items. 

(3)  Block  3.  The  smallest  value  just  found  in  the  resigned  array 
is  set  to  a  very  large  negative  value  to  essentially  remove  it  from  further 
consideration. 

(4)  Block  4.  The  index,  K,  is  incremented  until  the  total  number 
of  array  items  has  been  ranked. 

17.  ROUTINE  SCALE: 

a.  Purpose.  This  routine  adjusts  the  value  of  X  to  fall  within  a 
specified  interval.  An  example  of  use  is  to  scale  an  angle  in  radians  to 
between  zero  and  2r. 


b.  Input  Variables: 

Name  Source  Contents 


X 

Call 

The 

value 

to  be 

scaled. 

XLO 

Call 

The 

lower 

limit 

of 

the  specified 

interval. 

XU? 

Call 

The 

upper 

limit 

of 

the  specified 

interval. 

c.  Output  Variables: 

Name  Destination  Contents 

SCALE  Call  The  scaled  value  of  X. 

d.  Logical  Flow  (Figure  IV-19-B-8): 

(1)  Block  1.  The  scale  interval  is  the  difference  in  the  specified 
upper  and  lower  limits. 

(2)  Block  LI.  The  current  value  of  X  is  compared  with  the  upper 
limit  of  the  scale  interval. 

(3)  Block  2.  If  the  current  value  of  X  exceeds  the  upper  limit, 
subtract  one  interval. 

(4)  Block  L2.  If  the  current  value  of  X  is  within  the  upper 
limit,  the  current  value  of  X  is  compared  with  the  lower  limit. 
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Figure  IV-19-B-8.  Routine  SCALE 
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(5)  Block  3.  If  Che  current  value  of  X  is  below  the  lower  limit, 
add  one  interval. 

(6)  Block  L3.  If  the  current  value  of  X  is  above  the  lower  limit, 
the  current  value  of  X  is  returned  to  the  calling  routine. 

18.  ROUTINE  DNOEM: 

a.  Purpose.  This  function  returns  an  approximation  of  the  cumulative 
fraction  of  the  area  beneath  the  normal  curve,  given  a  position  along  the 
curve  in  standard  deviations. 

b.  Input  Variables: 

Name  Source  Contents 

Y  Call  Position  along  the  curve,  in  standard  deviations 

from  the  mean. 

c.  Output  Variables: 

Name  Destination  Contents 

DNORM  Call  Cumulative  fraction  of  the  area  beneath  the 

normal  curve  at  point  Y. 

d.  Processing  Description.  Hasting's  approximation  number  63  is  used. 
DNORM  is  set  to  zero  or  one  if  absolute  value  of  Y  is  greater  than  5.2. 

19.  ROUTINE  ENORM: 

a.  Purpose,  This  routine  generates  a  random  variable  from  a  normal 
distribution  with  mean  of  zero  and  standard  deviation  as  given. 

b.  Input  Variables: 

Name  Source  Contents 

SGM  Call  Standard  deviation. 

c.  Output  Variables: 

Name  Destination  Contents 

ENORM  Call  Value  of  the  random  variable. 

d.  Processing  description.  A  uniform  random  number  is  generated  by 

a  call  to  RANDU,  that  is  a  cumulative  probability.  Hasting's  approximation 
number  68  is  used  to  convert  to  a  normal  standard  deviate,  and  the  result  is 
multiplied  by  SGM. 
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20.  ROUTINE  FNORM: 


a.  Purpose.  This  routine  returns  an  approximation  of  the  position  along 
the  normal  curve,  in  standard  deviations,  corresponding  to  a  given  cumulative 
fraction  of  the  area  beneath  the  curve. 


b.  Input  Variables: 
Name  Source 


Contents 


A 


Call 


Cumulative  fraction  of  the  area  beneath  the 
normal  curve. 


c.  Output  Variables: 
Name  Destination 


Contents 


FNORM  Call 


Position  along  the  normal  curve,  in  standard 
deviations . 


d.  Processing  Description.  Hastings  approximation  number  68  is  used 
to  calculate  the  conversion. 


21.  ROUTINE  RANDU: 


a.  Purpose.  This  routine  is  used  to  generate  a  uniformly  distributed 
random  number.  It  uses  the  equation: 


Xi  +  1 

«  Xi(210  +  3)  +  1  Mod  220 

(IV-19-B-4) 

b. 

Input  Variables: 

Name 

Source 

Contents 

XI 

Call 

The  lower  limit  of  the  random 
returned. 

number  to  be 

X2 

Call 

The  upper  limit  of  the  random 
returned. 

number  to  be 

RNDSED 

ONE 

Last  random  number  computed. 

c. 

Output  Variables: 

Name 

Destination 

Contents 

RANDU 

Call 

The  random  number  generated. 
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d.  Logical  Flow  (Figure  IV-19-B-9): 

(1)  Block  1.  The  previous  random  number  RNDSED  is  multiplied  by 
210  which  has  the  effect  of  shifting  left  by  10  bits.  The  resulting  value 
is  added  to  RNDSED  three  times. 

(2)  Block  2.  A  one  is  added  to  the  result.  The  four  high  order 
bits  are  masked  out  to  perform  the  modulo  2^0.  The  result  is  stored  in 
RNDSED. 

(3)  Block  3.  The  interval  range  is  computed  by  subtacting  XI  from 
X2. 

(4)  Block  4.  RANDU  is  calculated  by  multiplying  the  interval  range 
by  the  value  in  RNDSED  divided  by  2^0.  XI  is  added  to  the  result . 

22.  ROUTINE  RAND1: 

a.  Purpose.  This  routine  is  used  to  seed  the  random  number  generator. 
It  is  called  only  once  per  game. 


b. 

Input  Variables: 

Name 

Source 

Contents 

XI 

Call 

Seed  Value. 

c. 

Output  Variables: 

Name 

Destination 

Contents 

RNDSED 

Call 

Initial  seed  for  random  number 

generator. 

d. 

Logical  Flow  (Figure 

IV-19-B-9):  Put  seed  value,  XI, 

in  RNDSED, 

and  return  control  to  the  calling  routine. 

23.  ROUTINE  IUIDF: 

a.  Purpose.  This  routine  is  used  to  determine  the  position  of  a  unit 
in  the  unit  identification  table. 

b.  Input  Variables: 

Name  Source  Contents 

UID  Call  The  eight-character  unit  identification  to  be 

located. 

BPOINT  ONE  The  location  in  the  unit  identification  table 

of  the  last  Blue  unit. 
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Name 


Source 


Concents 


RPOINT  ONE 


The  location  in  the  unit  identification  table 
of  the  first  Red  unit. 


UIDTAB (2 , 1000)  TWO 


c.  Output  Variables: 


Table  containing  unit  identifications  of  all 
played  units. 


Name  Destination 


Contents 


IUIDF  Call 


Relative  location  of  unit  in  unit  identification 
table. 


d.  Logical  Flow  (Figure  IV-19-B-10): 

(1)  Block  1.  Set  IUIDF  to  zero. 

(2)  Block  2.  If  the  unit  is  a  Red  force  unit,  transfer  control  to 

block  4. 

(3)  Block  3.  Since  this  is  a  Blue  force  unit,  store  the  points 
where  search  is  to  be  processed.  Control  goes  to  block  5. 

(4)  Block  4.  Since  this  is  a  Red  force  unit,  store  the  points  where 
search  is  to  be  processed.  Control  goes  to  block  5. 

(5)  Block  5.  If  search  is  completed,  return  control  to  the  calling 
routine;  otherwise,  it  goes  to  block  6. 

(6)  Block  6.  If  the  first  word  (first  four  characters)  of  the  unit 
identification  matches,  control  goes  to  block  7;  otherwise,  transfer  control 
to  block  5  and  continue  the  search. 


(7)  Block  7.  If  the  second  word  (last  four  characters)  of  the  unit 
identification  matches,  control  goes  to  block  8;  otherwise,  transfer  control 
to  block  5  and  continue  the  search. 


(8)  Block  8.  A  match  was  found;  so,  reset  IUIDF  to  relative  location 
in  unit  identification  table  and  return  control  to  the  calling  routine. 

24.  ROUTINE  ADDUNT: 


a.  Purpose.  This  routine  assigns  IUID  numbers  to  units  defined  by  UIDs 
and  accordingly  stores  the  unit  identification  of  each  unit  in  common  TWO. 

b.  Input  Variables: 

Name  Source  Contents 

UID  Call  Eight-character  unit  identifier. 
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Name 


Source 


Contents 


BPOINT 

ONE 

The  location  in  the  unit  identification 
of  the  last  Blue  unit. 

table 

RPOINT 

ONE 

The  location  in  the  unit  identification 
of  the  first  Red  unit. 

table 

c.  Output 

Variables : 

Name 

Destination 

Contents 

IUID 

Call 

Unit  identifier  (serial  number) . 

UIDTAB (2,1000) 

TWO 

Unit  identification  table. 

BPOINT 

ONE 

The  location  in  the  unit  identification 
of  the  last  Blue  unit. 

table 

RPOINT 

ONE 

The  location  in  the  unit  identification 
of  the  first  Red  unit. 

table 

d.  Logical  Flow  (Figure  IV-19-B-11) : 

(1)  Block  1.  Whether  unit  is  Blue  or  Red  force  is  determined  from 
the  first  character  of  the  unit  identification  code. 

(2)  Blocks  2  and  3.  The  counter  of  units  assigned  IUIDs  in  the 
respective  force  is  adjusted. 

(3)  Blocks  4  and  5.  The  IUID  is  assigned. 

(4)  Block  6.  The  unit  identification  is  stored  in  the  unit  identi¬ 
fication  table.  Control  returns  to  the  calling  routine. 

25.  ROUTINE  E0H20T: 

a.  Purpose.  This  routine  computes  secondary  equipment  losses  and  adds 
them  into  the  equipment  loss  table  in  the  IOUT  buffer  area. 

b.  Input  Variables: 

(1)  Standard  Common  Block  Areas.  TOUT  and  IER. 

(2)  Other  Variables: 

Name  Source  Contents 


JUID 


Call 


IUID  of  unit  being  assessed. 


Figure  IV-19-B-11.  Routine  ADDUNT 
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Name 

Source 

Contents 

JFORCE 

Call 

Force  indicator: 

0  =  LSE0H2  is  in  core. 

1  =  Blue  force  and  LSE0H2  is  not  in  core. 

2  =  Red  force  and  LSE0H2  is  not  in  core. 

EOHTBL 

Call 

Equipment  on  hand  table  of  unit  being  assessed 

LSE0H2 

Call  or  DF6 

Secondary  loss  table. 

AUTEOH 

DF50 

Unit  authorized  equipment  table. 

EQPOUT 

ONE 

Primary  equipment  loss  table. 

c. 

Output 

Variables : 

Name 

Destination 

Contents 

EQPOUT 

ONE 

Equipment  loss  table  with  secondary  losses 
added. 

d. 

Logical 

Flow  (Figure 

IV-19-B-12): 

(1)  Block  1.  If  the  secondary  loss  table  (LSE0H2)  is  not  in  core, 
retrieve  it  from  data  file  6.  The  variable  JUID  is  used  as  a  record  pointer 
to  data  file  50  to  obtain  the  authorized  equipment  table  (AUTEOH) . 

(2)  Block  2.  If  there  are  no  primary  losses  associated  with  first 
or  next  item  or  if  it  does  not  have  secondary  equipment,  transfer  control  to 
block  4. 

(3)  Block  3.  This  code  calculates  the  amount  of  each  secondary  item 
lost  and  adds  that  amount  into  the  loss  table  (EQPOUT) .  To  determine  the 
amount  of  the  secondary  item  lost,  the  ratio  of  the  amount  of  that  item  on 
hand  to  the  authorized  amount  (RATIO)  is  calculated.  The  amount  of  loss  is 
equal  to  the  product  of  RATIO,  the  number  of  primary  items  lost,  and  the 
number  of  secondary  items  per  primary  item. 

(4)  Block  4.  If  all  items  in  the  prirary  item  table  have  not  been 
processed,  return  control  to  block  2. 

26.  ROUTINE  PUTOUT: 

a.  Purpose.  This  routine  transfers  output  records  from  common,  IOUT,  to 
duplicate  Period  History  tapes  39  and  40. 

b.  Input  Variables: 

Name  Source  Contents 

J  Call  Code  for  portion  of  words  to  be  transferred: 

1  ■  first  128  words;  2  ■  second  128  words; 

3  ■  all  256  words. 
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Figure  IV-19-B-12.  Routine  E0H20T 
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Name 


Source 


Contents 


IOUT(256)  ONE  Block  of  up  to  256  words  of  stored  output 

records  generated  by  a  Period  Processor 
routine. 


c.  Output  Variables: 

Name  Destination  Contents 

IOUT(256)  Period  History  Output  records  generated  by  a  Period  Processor 
tapes  routine. 

d.  Logical  Flow  (Figure  IV-19-B-13): 

(1)  Block  1.  The  input  variable  J  is  tested.  If  the  value  is 
neither  1,  2,  nor  3,  XXIT  is  called  with  error  indication.  If  J  equals  2, 
control  is  transferred  to  block  L10. 

(2)  Block  2.  The  first  128  words  of  array  IOUT  are  written  to  magnetic 
tape  files  TAPE39  and  TAPE40. 

(3)  Block  3.  If  J  equals  one,  return  control  to  the  calling  routine. 

(4)  Block  L10.  The  second  128  words  of  array  IOUT  are  written  to 
magnetic  tape  files  TAPE39  and  TAPE40;  then,  control  returns  to  the  calling 
routine. 

(5)  Block  L20.  Routine  XXIT  is  called  to  terminate  processing. 

Control  returns  to  the  calling  routine. 

27.  ROUTINE  SCORE: 


a.  Purpose.  This  routine  maintains  the  battle  score  board  on  data 
file  48  by  assigning  each  unit  that  is  assessed  a  record.  On  this  record 
a  running  total  of  losses  sustained  by  the  unit  during  any  game  period  is 
kept.  The  losses  are  kept  in  terms  of  item  code  and  personnel  versus  fire 
type  causing  the  assessment  (KILLER).  Six  types  of  fire  are  recognized; 
ground  combat,  direct  aerial  fire  support,  close  air  support,  artillery, 
nuclear,  and  air  defense  fire. 


b.  Input  Variables: 
Name  Source 

IUSF  Call 

KILLER  Call 


Contents 


Unit  status  record  of  unit  suffering  losses. 

GCM  -  Ground  combat 

DAFS  -  Direct  aerial  fire  support 

CAS  -  Close  air  support 

ARTY  -  Artillery 

NUCL  -  Nuclear 

ADFR  -  Air  defense  fire 
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Name 


Source 


Contents 


NUMBER 

Call 

Centiminutes  of  ground  combat,  number  of  air 
sorties,  number  of  artillery  rounds,  or  number 
of  air  defense  firing  units. 

IARRAY 

DF48 

Table  of  losses. 

c. 

Output  Variables: 

Name 

Destination 

Contents 

IARRAY (202) 

DF48 

Updated  table  of  losses. 

d. 

Logical 

flow  (Figure 

IV-19-B-14) : 

(1)  Block  1.  If  the  unit  has  not  been  assigned  a  score  board  record 
on  data  file  48,  it  is  assigned  the  next  one  available.  Each  word  of  the 
record  is  set  to  zero  initially. 


(2)  Block  2.  If  all  the  records  in  data  file  48  have  been  used, 
five  records  are  added  to  the  file,  by  means  of  ADDRCD,  and  this  unit  is 
given  the  first  of  the  new  records. 

(3)  Block  3.  Match  the  variable  KILLER  with  one  of  the  character 
codes  described  as  input.  If  a  match  is  not  found,  an  error  message  is 
written  and  control  returns  to  the  calling  routine;  otherwise,  the  word 
pointer  into  the  score  board  record  is  set  to  the  appropriate  value. 

(4)  Block  4.  The  old  loss  array  associated  with  this  type  of  fire 
(IARRY)  is  retrieved  from  the  score  board  record  and  is  updated  by  adding 
the  current  losses.  The  first  word  of  IARRY  contains  a  running  total  of 
the  variable  NUMBER,  the  second  word  contains  the  personnel  losses,  and  the 
remaining  200  words  correspond  to  the  200  items  of  equipment. 

28.  ROUTINE  BUFOUT: 

a.  Purpose.  This  routine  is  used  to  save  the  4102-word  array  IDUM  in 
common  TWO  by  writing  it  to  data  file  36.  Thus,  IDUM  locations  can  be  used 
by  another  routine  and  can  be  restored. 

b.  Input  Variables.  IDUM. 

c.  Output  Variables.  IDUM. 

d.  Logical  Flow.  BUFOUT  calls  routine  PUTWRD  to  write  the  array  IDUM 
to  data  file  36. 

29.  ROUTINE  BUFFIN: 

a.  Purpose.  This  routine  is  used  to  retrieve  the  4102-word  array  IDUM 
from  data  file  36. 
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b.  Input  Variables.  IDUM. 

c.  Output  Variables.  IDUM. 

d.  Logical  Flow.  BUFFIN  calls  routine  GETWRD  to  retrieve  the  array 
IDUM  from  data  file  36. 

30.  ROUTINE  KPICK: 

Not  used. 


31.  ROUTINE  BLKDAT.  This  is  a  BLOCK  DATA  routine  that  is  used  to 
initialize  data  stored  in  common.  See  ANSI  FORTRAN  reference  manual. 

32.  ROUTINE  GET: 

Not  used. 


IV-19-B-39 


I 


APPENDIX  C 

OUTPUT  DESCRIPTIONS  FOR  UTILITY  ROUTINES 


The  utility  routines  of  the  DIWAG  Period  Processor  return  requested  data 
to  the  calling  routine.  There  is  no  printed  output. 


IV-19-C-1 


I 


APPENDIX  D 

SOURCE  LISTINGS  FOR  PERIOD  PROCESSOR  UTILITY  ROUTINES 


(AVAILABLE  UNDER  SEPARATE  COVER) 
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